RFC: New DBD keyword?

["Johnson, Andrew N." <anj@aps.anl.gov>]

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