EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Fundamental Types / Gateway
From: "Jeff Hill" <[email protected]>
To: "'Marty Kraimer'" <[email protected]>, "'EPICS Core Talk'" <[email protected]>
Date: Fri, 17 Jun 2005 17:25:15 -0600
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  <20052006  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  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·