EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RFC: New DBD keyword?
From: "Johnson, Andrew N." <[email protected]>
To: "[email protected]" <[email protected]>
Date: Mon, 2 May 2016 03:59:03 +0000
I've been continuing to work on my Link Support development, starting on the task of adding generic link types that will use a JSON object for addressing. Before I commit my next set of changes I thought I should check on other developers' thoughts on my continuing to add keywords to the DBD file syntax.

In this case I'm planning to add
  link(key, LSETname)
where the LSETname is the symbol name for the link support table and key is the name of the link type which is used to select that type in the link value string, e.g.
  link("pva", lsetPvAccess)
would allow this kind of link:
  field(OUTA, "{\"pva\":{\"pv\":\"v4channel\",\"pvRequest\":\"process=true\"}}")

Having to escape all those double-quotes in the JSON is annoying, but that's a natural part of the DB syntax and hopefully our tools will handle that for us. The point of the link statement is to allow database configuration tools to know that pva is a valid link type, and it helps ensure that hidden keys don't get registered nor keys reused. I'm not currently planning to document/describe the internal structure of the JSON link in the DBD though, which could get complicated.

The alternative to adding this keyword would be to just have a registrar routine register the name and LSET in C code.

The existing link syntax will continue to be supported. The only limitation I have to add is to forbid record names from starting with an open-brace character '{' but since braces are not strictly legal characters anyway right now that shouldn't be a problem. The NSLS-2 naming convention does use braces in record names, but there is no clash with this requirement since those PV names never start with a brace.

One advantage of the new syntax should be the ability to support strings and arrays as constant values, e.g.
    field(INP, "{\"const\":[1,2,3,4,5]}")

Any comments?

- Andrew

-- 
Sent from my iPad

Replies:
Re: RFC: New DBD keyword? Michael Davidsaver

Navigate by Date:
Prev: Jenkins build became unstable: epics-base-3.14-win32s #114 APS Jenkins
Next: Re: RFC: New DBD keyword? Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Jenkins build is back to stable : epics-base-3.14-win32s #115 APS Jenkins
Next: Re: RFC: New DBD keyword? Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 May 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·