EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: extensible link support example
From: Benjamin Franksen <[email protected]>
Cc: EPICS core-talk <[email protected]>
Date: Thu, 2 Jun 2016 17:04:48 +0200
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.

There are at least two alternatives.

One is to use JSON throughout, providing a tool that converts the old
syntax to the new one. The old parser can be added to an IOC as an
optional component for compatibility, if desired.

The other is (I have made similar proposals in the past) to stick with
the core of the current db/dbd syntax, which has roughly the following
shape (where * is the meta-character for zero or more repetitions):

  start ::= item*
  item ::= keyword "(" parameters ")"
  item ::= keyword "{" item* "}"
  item ::= keyword "(" parameters ")" "{" item* "}"
  parameters ::= atom
  parameters ::= atom "," parameters
  atom ::= <string or number>

The idea is now to make the syntax pluggable: allow user code to
register new keywords, telling the generic parser what function to call
for the new kind of items (and its sub items). Items with unknown
keywords are parsed (so we find where they end) but otherwise ignored.

For instance, scalar array literals could be implemented with a new
keyword 'array' that expects no sub-items and arbitrary number of
parameters for the elements.

Here is your example from the wiki in my proposal:

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 should be allowed here, too
        db() {
            pv("$(IOC):dblink")
            MS(true)
        }
    }
    field(INPE) { # yet another variant, how many do you want to allow?
        db("$(IOC):dblink") {
            MS(true)
        }
    }
    # and yet another variant, there are 100s of possibilities
    field(INPE,"$(IOC):dblink") {
      type(db)
      flags(MS,NPP)
    }

    # leaving out the channel access links as I don't know
    # what the ts:{} is for and anyway the idea should be clear

    # These are constant arrays
    field(INPJ) { array(1, 2, 3, 4, 5) }
    field(INPK) { array("An array with one string element") }

    # New style info-tag
    info(autosave) {
        fields(SCAN, DESC)
        pass0(VAL)
    }
}

Here I have extended the keyword 'field' to accept not only two
parameters and no sub items (as it does now) but also one parameter with
sub items (e.g. 'db'). The exact structure of the extended link
specification is of course up to discussion. (I think we should not
allow too many variations that mean the same thing.)

Cheers
Ben
-- 
"Make it so they have to reboot after every typo." ― Scott Adams

Attachment: signature.asc
Description: OpenPGP digital signature


Replies:
Re: extensible link support example Andrew Johnson
References:
Re: extensible link support example Andrew Johnson

Navigate by Date:
Prev: Re: extensible link support example Andrew Johnson
Next: Re: extensible link support example Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: extensible link support example Andrew Johnson
Next: Re: extensible link support example Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Jun 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·