Re: EPICS V4; Plan 17.6

[Kay-Uwe Kasemir <kasemirk@ornl.gov>]

On Oct 14, 2005, at 09:54 , Ralph Lange wrote:
> What will be the interface between the network server (be it ICE or  
> CA based) and the IOC database?
> The new approach that Matthias and Ned will be presenting seems to  
> be strictly driven by application needs and may not be desirable or  
> even usable between the IOC database and the network server.
It's true that the application needs will firstly result in
a 'control system data access' API on the client side.
What's wrong with that?
Based on it, four things can happen in parallel:
- we can find a better name for the 'EPICS Office' application suite
- we can implement this control system application suite
  based on the access API
- we can implement the access API for V3 Channel Access and
  other protocols
- we can work on the V4 IOC code to support new data types,
  custom event subscription, ...

As we now know, few EPICS sites actually care to support the latter.
At the EPICS meeting, no new project was presented.
New developments were: a rewrite of the motor record,
tcl as an ioc shell, makefiles for compiling both R3.13 and R3.14.
Hardware platforms are shrinking, and people worry
about CPU and memory footprints, about the overhead of redundancy.
LANL prefers 'dynamic records' for handling beam flavor,
SNS uses a 'correlator' on the client side.

I would hope that once we have the first fancy pieces of the application
suite, more sites will be interested in getting new IOC code that
actually provides the new data types, events, ...

-Kay

> Marty Kraimer wrote:
> > > The proof of concept will consist of client code communicating  
> > > with  an IOC database.  For the proof of concept, only skeleton  
> > > code is  required.
> > > Perhaps Kay and possibly someone from COSYLAB could implement  
> > > the  client code and Marty and Andrew the IOC code. At the same  
> > > time (or whenever possible), Jeff can adjust his Data Access/ 
> > > network protocol to accommodate the API.