As I recall, only db_access knows the behavior (mapping) associated with a DBR_CLASS_NAME request, and that the CA client and server only know that this is another DBR type which is stored as a string.
Perhaps the only issue is that the GW isn’t caching the DBR_CLASS_NAME PV attribute? Another possibility might be that the GDD to DBR conversion stuff was written before DBR_CLASS_NAME was added.
Jeff
> -----Original Message-----
> From: Ralph Lange [mailto:[email protected]]
> Sent: Thursday, January 08, 2009 6:57 AM
> To: 'Ernest L. Williams Jr.'
> Cc: Jeff Hill; 'Andrew Johnson'; EPICS Core Talk
> Subject: Re: RTYP field through the PV Gateway
>
> 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:tech-talk-
> [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
> >>
> >
> >
> >
- References:
- Re: RTYP field through the PV Gateway Ralph Lange
- Navigate by Date:
- Prev:
Re: RTYP field through the PV Gateway Kasemir, Kay
- Next:
Re: RTYP field through the PV Gateway Andrew Johnson
- 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: RTYP field through the PV Gateway Kasemir, Kay
- Next:
Re: RTYP field through the PV Gateway Andrew Johnson
- Index:
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|