Hi - I moving this over to core-talk for the gory details....
RTYP is a pseudo field: When a read request for a "*.RTYP" PV comes in,
the CA client library strips the ".RTYP" and converts it to a
DBR_CLASS_NAME request.
When the CA server in the IOC (rsrv) gets that request, it finds out the
record type of the EPICS record that the PV belongs to and returns the
name of that record type as a string.
So an intermediate layer like the Gateway will probably have to
re-convert the DBR_CLASS_NAME request for "XXX" to a simple request for
"XXX.RTYP", so that the data can be held in the usual cache structures.
Then the Gateway's CA client side will properly recode the request to
DBR_CLASS_NAME.
Actually I have no idea why "finding out the record type as a string"
was implemented in that way, instead of adding support for an additional
(maybe pseudo) field in the EPICS database. The pseudo field approach
contradicts a number of well-accepted design ideas and concepts:
1. It bloats the protocol (by adding another DBR type).
2. It restricts (probably undocumented) the naming of EPICS database
fields. (I refuse trying to imagine what creating a "real" field named
RTYP would result in.)
3. For non-EPICS uses of CA (gateway through a CAS to something
completely different) it imposes the EPICS-like naming ".RTYP" that
might make no sense ore even create a conflict within the completely
different naming scheme.
4. It forces an intermediate layer to add exception code (see above).
An implementation that just transparently forwards the read request to a
PV "XXX.RTYP" like any other read request and lets the EPICS database
code return that special record type name would IMHO be a much cleaner
solution. Things like the gateway would just work without any added
complexity.
Do I miss some important advantage of the pseudo field implementation? I
can't think of one and (as I know this feature has been added later on)
I guess there should be a few. Jeff, what am I missing here?
The only other case of CA-EPICSdb dependency (that I know of) is adding
the ".VAL" extensionsto PVs without a field name. I don't know if this
is done by the client or the server right now - it should be done on the
server side for the same reasons.
Cheers,
Ralph
Jeff Hill wrote:
Summarizing the issue; this PV attribute, "DBR_CLASS_NAME", isn't currently
maintained in the gateway's cache. The symptom must be that its
communicating properly through both sides of CA, but not through the
gateway.
I am not aware that anyone is working on this, but Ralph Lange would be the
best person to consult concerning current projects in progress with the
gateway.
Jeff
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Andrew Johnson
Sent: Wednesday, January 07, 2009 8:29 AM
To: [email protected]
Cc: Ernest L. Williams Jr.
Subject: Re: RTYP field through the PV Gateway
Hi Ernest,
On Wednesday 07 January 2009 00:15:17 Ernest L. Williams Jr. wrote:
Is anyone working to add the "DBR_CLASS_NAME" to the gateway so that it
handles the RTYP field in an EPICS record?
I'm not aware of anybody doing so. Why can't you just ask for the .RTYP
field
name (which is really an automatically created record attribute) directly?
- Andrew
--
The best FOSS code is written to be read by other humans -- Harold Welte
- Replies:
- Re: RTYP field through the PV Gateway Kasemir, Kay
- RE: RTYP field through the PV Gateway Jeff Hill
- Re: RTYP field through the PV Gateway Andrew Johnson
- Navigate by Date:
- Next:
Re: RTYP field through the PV Gateway Kasemir, Kay
- Index:
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
- Navigate by Thread:
- Next:
Re: RTYP field through the PV Gateway Kasemir, Kay
- Index:
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
|