Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Fri, 17 Jun 2005 22:09:26 +0200

On Friday 17 June 2005 17:48, Marty Kraimer wrote:
> Ralph Lange wrote:
> > What I really like to have (if I had a free wish...) for the
> > Gateway is a completely opaque black-boxed data store.
>
> A wish is not an implementation and actually not even an interface
> :-)

Dear Marty,

the interface /is already there/! It is called Data Access. Yes, Ralph's 
wish is not an implementation. Note: Andrew said he wished we would 
first arrive at a specification and then start hacking. Of course, if 
there are open questions as regards the intended semantics of DA 
operations, then these must be clarified.

> This is really important. We must see how to implement the data store
> for a CA gateway.
> If someone can create code to describe, store, and transport all data
> we have discussed so far via just the Data Access definitions then
> please tell us how to do it.

Yes. But before that, let us agree that DA is the interface. Or else let 
us state precisely in what regard DA is /not/ capable of handling all 
the requirements we have, and then fix DA so that we are all happy with 
it.

I agree that it makes (a lot of) sense to explore the /possibility/ to 
implement such a data store efficiently before finally committing to an 
interface. But it is definitely not necessary to have a working 
prototype. It's enough to be reasonably sure that we will find 
solutions to any as yet unsolved problems. Furthermore, as Ralph stated 
explicitly, as soon as we are convinced that the interface really 
covers everything we want it to, we can spend every effort necessary to 
optimize the data store. We could even start and read advanced 
literature on how to do stuff like that, including things such as 
on-line code optimization etc...

> Let me just make a wild proposal that involves allowing only well
> defined types.
>
> GIVEN
>
> The types
>
> primitive
>      bool,
>      octet,
>      int16,
>      ...
>      float64
> string
> array
> struct   - can contain fields of any type including itself
>
>
> And via these types define a way to introspect.

Correct me if I am wrong, but IIRC these types are a /subset/ of those 
DA supports. The primitive types are named differently, i.e. using 
'native' C++ type names. The structured types are covered, too, maybe 
not yet in all necessary detail. These can and must be worked out. 
Great effort has been spent to try and make DA the Right Thing. I think 
it at least deserves to be treated as the starting point for further 
development. I am somewhat suspicious of ad-hoc solutions to try and 
re-invent the wheel once again.

Note: Keep in mind that this is /not/ about the low-level representation 
of EPICS records on the IOC. As regards the latter, of course we will 
need a way to store compound record data in the IOC so that we will 
have the most efficient access from the record support. I would argue 
that we don't need to hide any data representation behind bars of any 
kind, but instead give record support complete unsafe low-level access, 
supported by C routines for convenience only.

And, as Ralph already stated, this low-level data representation for 
EPICS records /can/ be /used/ by some generic Data Store. To d so would 
be economic, at least for the first version, but it is by no means 
necessary and any such use will be completely opaque to users of a 
generic Data Store.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System