Experimental Physics and Industrial Control System
Marty,
> This is really important. We must see how to implement the data store
> for a CA gateway.
GDD was originally designed for this job. Each GDD is a discriminated union
of all scalar primitive types. A GDD also includes a property type
identifier, time stamp, status, bounds, and other fields. GDD themselves can
be containers of other GDDs. GDDs biggest failing was that it is an
implementation of data storage and not an interface to data storage. A very
general (runtime bound) approach was selected for the gateway, but that
unfortunately imposes a huge storage and efficiency penalty for many other
data storage situations.
My conclusion was that the purpose specific code itself is almost always
better off defining the structure of its data which might be then interfaced
to data access should it need to be accessed as data by other entities.
Whoever ends up implementing the next gateway must decide if GDD should be
used or not. I can think of some other possibilities.
1) A simple approach might be to implement a free list for each scalar
primitive type storing properties for each PV in their native type on a
linked list. That would take care of scalars. Arrays might be stored in
non-contiguous fixed sized blocks in a linked list to improve efficiency.
This could be viewed as an optimized version of GDD saving space by using a
pure virtual interface and different implementations for different types of
data. GDD didn't do that. We would still have a linked list of properties
for each PV similar to GDD with this approach however. There would need to
be some way to index properties efficiently within this linked list.
2) A more sophisticated approach might use non-contiguous fixed sized blocks
to store all properties for a PV. Properties would be packed into these
buffers using some sort of protocol. A header for each PV would provide some
sort of indexing scheme into the packed properties so that they could be
efficiently extracted as needed. This approach might use less storage, and
presumably could be just as fast when indexing properties.
3) An even more sophisticated technique would query the server for the
"class name" of its PV when connecting. The gateway would then traverse all
of the properties for that class of PV on that server and build only one
indexing authority for that class of PV on that server. The individual PVs
would still be stored using a protocol into non-contiguous fixed sized
blocks, but the indexing authority would need to be stored only once for
each "class" of PV.
Of course, with either approach a data access interfacing code would need
also to be written.
CA will of course also have the job of converting ordered lists of
properties into a protocol. The user will define data types which are just
lists of properties, and CA will pack these types on the wire not sending
the description of the data with each instance of the data. It sounds like
there could be some implementation overlap with a sophisticated GW, and
opportunities for shared code.
> 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.
>
>
> THEN
>
>
> Then I claim that we can create code to describe, store, and transport
> all data we have discussed so far.
>
> It would mean that anything interfacing to CA must use only this set of
> types for data.
CA will interface to *any* data that is interfaced with Data Access. Not
just one implementation or only one set of size locked types.
Data Access is interfacing to whatever C++ primitive types are selected by
the user to define his data (size locked or otherwise). CA will discover the
byte size of the user's data when traversing it, and can properly encode it
into network protocol at that time. I have defined size locked types in the
past - i.e. dbr_float_t and my experience has been that almost no one uses
them. With Data Access we don't make authoritarian demands on the user's
data types. Instead, we learn and adapt to whatever type and size of data
the user is actually using and transform it to wire protocol as is needed.
We interface to data, but don't define its structure.
An important requirement is to detect out of range conditions when
converting between different types, and report them as errors to the user.
These checks (performed by data access) are based on the number's magnitude
and not just on its type. Therefore writing an int to an unsigned char will
not fail unless the int stores a value that isn't expressible as an unsigned
char.
Sorry to repeat the same mantra, but paragraphs such as the above lead to
guesses that maybe the Data Access design principals still need to be
discussed.
Jeff
> -----Original Message-----
> From: Marty Kraimer [mailto:[email protected]]
> Sent: Friday, June 17, 2005 9:49 AM
> To: EPICS Core Talk
> Subject: Re: Fundamental Types / Gateway
>
>
>
> 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 :-)
>
> 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.
>
> 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.
>
>
> THEN
>
>
> Then I claim that we can create code to describe, store, and transport
> all data we have discussed so far.
>
> It would mean that anything interfacing to CA must use only this set of
> types for data.
>
>
> Marty
>
>
>
- References:
- Re: Fundamental Types / Gateway Marty Kraimer
- Navigate by Date:
- Prev:
Re: Fundamental Types document Benjamin Franksen
- Next:
RE: Fundamental Types document / unsigned integers Jeff Hill
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Fundamental Types / Gateway Benjamin Franksen
- Next:
RE: Fundamental Types / Gateway Jeff Hill
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024