| 2002 2003 2004 2005 2006 2007 2008 <2009> 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 <2009> 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: RTYP field through the PV Gateway |
| From: | Ralph Lange <[email protected]> |
| To: | "'Ernest L. Williams Jr.'" <[email protected]> |
| Cc: | EPICS Core Talk <[email protected]> |
| Date: | Thu, 08 Jan 2009 14:56:53 +0100 |
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