Re: RFC: New DBD keyword?

[Michael Davidsaver <mdavidsaver@gmail.com>]

Hi Andrew,

>   field(OUTA, "{\"pva\":{\"pv\":\"v4channel\",\"pvRequest\":\"process=true\"}}")

umm... this looks quite ugly and verbose to me.  I know the present
situation wrt. parsing needs to be extended, but there has to be
something more readable.

> I'm not currently planning to document/describe the internal structure of the JSON link in the DBD though, which could get complicated.

Quite so.  However, unless this is done I don't see much benefit to
adding to the DBD.  Maybe better to leave this to code as with
iocshRegister() and similar.

In my mind the only reason I can see is to allow DCTs to assist in
formating/validating the link string.  The link type name is the part of
the string where I'm least likely to make a typo.

I'd advocate a more free-form approach of prefix matching (eg. "pva://")
and delegate parsing to plugin code.  As for providing hints for DCTs...
I don't have an answer yet.  The best I can think of is providing
regexps in the DBD.  Ugly, but mostly hidden.

>   link(key, LSETname)

As for extending the DBD syntax.  I'd point out you to my incomplete
project to build some forward compatibility into this parser.  The
extended syntax would cover your case.

https://github.com/mdavidsaver/epics-base/tree/extendb

https://github.com/mdavidsaver/epics-base/blob/extendb/src/ioc/db/test/dbParseTest2.db#L8

Michael


On 05/01/2016 11:59 PM, Johnson, Andrew N. wrote:
> 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
>