JSON Field Values

From EPICSWIKI
Revision as of 20:52, 1 June 2016 by AndrewJohnson (talk | contribs) (First pass)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

JSON Field Values

The current state of my Link Support development includes changes to the parsing of record instance data in database (.db) files.

At present the code adds the ability to parse simplified JSON in specific places in the .db file, and converts that to proper JSON stored in a string for later parts of the IOC parsing process. The places where I see JSON as being accepted are in record field values, and in info tag values. Some examples of JSON link addresses are shown below, although the specific syntax supported by the link types has not been decided yet so these are just illustrations of what might be possible. Note that currently only link fields would be expected to accept JSON objects, although the code shouldn't prevent additional support being added later for other field types if desired.

This modification does change the set of characters allowed in a bare-word string used as a field or info-tag value; the characters :, ;, <> and [] can no longer be used without enclosing the string inside double-quotes.

record(aSub, "$(IOC):sub1") {
    # These are all database links
    field(INPA, "$(IOC):dblink MS")
    field(INPB, {db:"$(IOC):dblink MS"})
    field(INPC, {db:["$(IOC):dblink", MS]})
    field(INPD, { # Comments are allowed inside JSON
        db: {
            pv:"$(IOC):dblink",
            MS:true
        }
    })

    # These are channel access links
    field(INPE, "remote:calink.{\"ts\":{}} CP")
    field(INPF, {ca:["remote:calink.{\"ts\":{}}", CP]})
    field(INPG, {ca:["remote:calink", {ts:{}}, CP]})
    field(INPH, {
        ca: {
            pv:"remote:calink",
            filter: {ts:{}},
            CP:true
        }
    })
    field(INPI, {ca:"$(IOC):dblink MS"})

    # This is a JSON-formatted info-tag
    info(autosave, {
        fields: [SCAN, DESC],
        pass0: [VAL],
    })
}

My rules for simplified JSON are that double-quotes are optional around any string (used as a key or a value) that only contains the characters a-z, A-Z, 9-0, _, -, + or .. The JSON keywords null, true and false will not be recognized as strings, nor will numbers that match the JSON encoding rules. Since JSON numbers don't include Infinity or NaN they will be recognized as unquoted strings, but should be handled correctly by the later parsing code. The # character can also be used inside simplified JSON to introduce a comment that lasts until the end of the current line.