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
<2016>
2017
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
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
|