Re: extensible link support example

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

Hi Ben,

On 06/02/2016 10:04 AM, Benjamin Franksen wrote:
> Am 01.06.2016 um 23:07 schrieb Andrew Johnson:
>> There was nothing written down before now other than the source code,
>> but I just created the Wiki page below to start collecting a spec. Doing
>> that already gave me the additional idea to allow comments inside the
>> JSON, which I immediately implemented:
>>
>> https://wiki-ext.aps.anl.gov/epics/index.php/JSON_Field_Values
> 
> Adding a subset of JSON in an ad-hoc manner like that makes the syntax
> (and thus parsing) *much* more complicated. Such a complication should
> be avoided if possible, and I am going to show that it is indeed possible.

Actually my implementation was designed to avoid making the dbStaticLib
parser significantly more complicated than it is, and to minimize the
changes needed to the parser code.

My additions to dbStaticLib cause any simplified JSON read from the file
to be converted into proper JSON in the string that gets passed into the
dbRecordField() routine in dbLexRoutines.c, so the YAJL parser that was
added to Base-3.15 can subsequently be used to parse that string. It
also strips extraneous spaces and comments so the string value contains
only the characters needed to hold the value.

My reasons for wanting to allow the simplified JSON input were so a user
writing DB files by hand doesn't have to provide all the double- quote
characters that JSON requires, and so DB file changes from our current
syntax are minimized (bareword string values are still allowed, although
some characters now need quotes that didn't before because they are used
syntactically by JSON). The DB file may contain proper JSON with all the
quotes if you want though.

The complication that my approach avoids is that the parsing of a JSON
link address happens much later, at iocInit() time. The dbStaticLib
parser just stores a JSON_LINK field's value string inside the link, and
since we might not even know what link types exist at that point it
wouldn't make sense to try and parse them further, other than syntax
checking.

As an example showing the simplicity of my approach, my change to allow
info tags to be written in JSON only modified 3 source lines and added
7; the applications that handle those tags will need to use YAJL to
parse the string if they want to accept JSON objects, but existing
applications won't have to be modified at all if they already do their
own parsing of the tag string.

Please take a look at my branch to get a better idea how it works:
  https://code.launchpad.net/~epics-core/epics-base/link-support-2


- 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

Attachment: signature.asc
Description: OpenPGP digital signature