Re: ICALEPCS and EPICS iocCore V4

[Claude Saunders <saunders@aps.anl.gov>]

I don't think the wide-interface, early binding discussions are really a 
part of the EPICS Core group. I agree with what appears to be the 
sentiment thusfar; namely that EPICS core needs a high-performance, 
connection managing, late-binding, channel-based protocol and interface.
I think the problem with EPICS longevity is that people don't look at it 
as a whole and see support for higher level abstractions anywhere. I 
think this needs to be addressed, but not by the EPICS core group.
I think the Fundamental Tools and Popular Extensions should perhaps be 
split into 2 groups:
1. Fundamental Tools and Clients
2. Middleware (device servers, gateways, nameservers, etc..)

The protocol and API between the middleware and (some, but not all) 
high-level applications will be something besides what EPICS Core group 
is working on. The middleware servers would also possibly do things that 
we would never want IOC Core to do, like access a relational database 
for magnet calibration parameters, etc.
This implies that clients of the control system would be faced with 2 
available APIs. One for straight, high performance access to EPICS PVs, 
and one for access to device abstractions (CORBA?). This winds up 
happening in some form anyway (ala SDDS, SNS Oracle, etc), so why not 
make some attempt at standardizing this within EPICS? Aside from the 
"not invented here" syndrome, I think this is largely why alternatives 
to EPICS are proliferating.
 - Claude