Re: RFC: New DBD keyword?

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

On 05/02/2016 07:19 PM, Michael Davidsaver wrote:
>>   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 agree, if you're writing it by hand at least. What if I teach the
dbStatic parser to understand JSON directly instead of embedding it
inside a string, so the above could become this:

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

A further step might be to drop the strict-JSON requirement and allow
this as well:

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

That one might be going a bit far since it would require DCTs to
implement their own parser for our not-quite-JSON format, but if we
wanted the DCTs to help in formatting/validating the field value we're
asking for a major overhaul from them anyway. I would consider going
this far if we decided to also provide some kind of schema for the JSON
object's internals, but TBH I think that would be asking quite a lot.

Note that this doesn't prevent a link/device support layer from doing
its own parsing of a string value:

 field(OUTA, {"pva":"v4channel[field=VAL] PP"})

I do like the flexibility of a JSON-link approach, for instance a link
might combine multiple channels into an array:

 field(INP, {"grp":["BPM1:Left", "BPM1:Right", "BPM1:Up", "BPM1:Down"]})

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon