1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 <2023> 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 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: Possible to create aliases for record fields? |
From: | Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> |
To: | Andrew Johnson <anj at anl.gov>, "Hu, Yong" <yhu at bnl.gov>, Zimoch Dirk <dirk.zimoch at psi.ch> |
Cc: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Tue, 3 Jan 2023 11:28:09 -0800 |
On 1/2/23 3:53 PM, Hu, Yong via Tech-talk wrote:
If "det1" is an IOC record, then "det1.RTYP" is definitely a PV name that the IOC will respond to. "RTYP" is a record attribute that the IOC adds to all record types, which returns the name of the record type. Some CA client applications (e.g. MEDM, capr.pl, CS-Studio's pvtree) query that attribute automatically for some/all of the channels they connect to, so a field alias such as the one suggested could result in the IOC seeing requests for that PV name.Michael, we are talking about fields here. So “det1:NELM.RTYP” itself is not valid.
Another (less important) use case is a script I
sometimes use to avoid developing OPI screens remotely.
Michael's question is thus a valid one. For a simple/naive implementation of this feature the answer might be that the channel name “det1:NELM.RTYP” would time out, and such field aliases just wouldn't support the capr.pl or pvtree applications at all in that case. That might be acceptable,
I think it is desirable to continue to support remote database
"crawling", although no necessarily with RTYP alone. Which has
obvious limitations in requiring a client to encode knowledge
about record types. An alternative which I occasionally think
about is adding another pseudo field which GETs a description of
the record type. eg. as a string (.dbd or some json) or
equivalent PVD structure.
but I would want to be shown that any implementation would not significantly increase the amount of work that the IOC's CA Search thread has to do.
Agreed. In both the positive and especially the negative case.