Experimental Physics and Industrial Control System
|
Marty Kraimer wrote:
It seems to me that a gateway has to address the same problem except
that it may be even harder. I will guess that a gateway will be able
to use everything in epicsTypes and also need something like dbdClass.
I am really interested in hearing Ralph's, Benjamin's etc thoughts on
how the gateway will manage storage. In particular how will it handle
the data connected to an arbitrary propertyId?
What I really like to have (if I had a free wish...) for the Gateway is
a completely opaque black-boxed data store.
The Gateway gets all its data (from the CA client library) through
DataAccess only. It has to provide the data (to the CA server library)
though DataAccess only. Any fixed kindOfDbdClass doesn't make too much
sense, as the Gateway (by definition) should not need to have any
knowledge about the internal structure of EPICS records. As it is a
ChannelAccess Gateway, not an EPICS Database Gateway, it shouldn't even
have to be aware of the mere existence of a concept called record. For
the Gateway, everything is channel names and DA property catalogs.
Back to my free wish:
When the Gateway gets new data from the CA client lib, it gets a
reference to a DA interface. My dream is to just issue a single call
into the data store saying "store this!" handing over the DA interface I
got from CA. The store would return another DA interface reference, this
time to the stored data. The Gateway would use this DA interface to push
up events to the CA server library. Once the data is not needed anymore,
it is returned to the store through another call saying "done!". At that
point the data store is free to do whatever it wants with the storage
that was returned. (Could that mechanism be replaced by reference
counting?? Maybe.)
In that fashion the Gateway wouldn't even have to care about internal
representation, basic, structured or additional epicsTypes, or anything
connected to how the stuff is kept.
The data store could engage any techniques or mechanisms to optimize the
hell out of storing the data. Using epicsTypes, free lists of memory
blocks sorted by natural type / size / color / smell, garbage
collection, a relational database, a paper card reader, whatever.
If DA implements a traversal for introspecting existing properties and
their native types, the data store itself can get all the info it needs
to organize storing the data. That kind of data store thing would be
very nice and handy for user level applications that have to accept,
keep and handle DA data. I guess the interface can be made dead-simple.
In this regard: Yes, in my dreams I would see the Gateway only using DA
to access and to store data.
Cheers,
Ralph
- Replies:
- Re: Fundamental Types / Gateway Marty Kraimer
- Re: Fundamental Types / Gateway Benjamin Franksen
- References:
- RE: Fundamental Types document Jeff Hill
- Re: Fundamental Types document Marty Kraimer
- Navigate by Date:
- Prev:
RE: Fundamental Types document Jeff Hill
- Next:
Re: Fundamental Types document Ralph Lange
- 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 document Marty Kraimer
- Next:
Re: Fundamental Types / Gateway Marty Kraimer
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|