Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #28659

Re: Static JSON parser for embedded

Subject Re: Static JSON parser for embedded
Newsgroups comp.lang.c, comp.arch.embedded
References <qblnbg$402$1@dont-email.me> <2hODE.56712$8B4.29775@fx02.iad> <qbp3ce$j92$1@dont-email.me> <Aj0EE.52260$fq3.52080@fx07.iad> <qdaldp$o7c$1@dont-email.me>
From Clifford Heath <no.spam@please.net>
Message-ID <z4hKE.2$3T5.0@fx45.iad> (permalink)
Date 2019-06-07 09:11 +1000

Cross-posted to 2 groups.

Show all headers | View raw


On 6/6/19 7:12 pm, pozz wrote:
> Il 19/05/2019 01:12, Clifford Heath ha scritto:
>> On 19/5/19 12:03 am, pozz wrote:
>>> Il 18/05/2019 09:14, Clifford Heath ha scritto:
>>>> On 17/5/19 5:20 pm, pozz wrote:
>>>>> I'd like to use JSON documents in my embedded project. I don't need 
>>>>> full parsing capabilities, because JSON could be very complex in 
>>>>> general.
>>>>>
>>>>> Do you know of something code generator?
>>>>
>>>> Ok. Latecomer, but I read most of the thread. Introduction: I've 
>>>> been writing C since 1979 and have a million lines of my code in 
>>>> production in mission-critical software on tens of millions of 
>>>> enterprise computers. Although these days my C is mostly C++, I use 
>>>> C++ mostly for the features that make it "a better C".
>>>>
>>>> Neither JSON nor C has a very strong type system. Neither is a good 
>>>> specification language. You should choose a specification language 
>>>> that does a good job of specifying your intent, and a compiler for 
>>>> it that emits C that handles one or more packing syntaxes such as 
>>>> JSON (if you must!)
>>>>
>>>> The European Space Agency has followed the lead of the ISO 
>>>> networking standards and built a compiler for ASN.1, which emits C 
>>>> code targeted at static-memory embedded systems. The downside: I 
>>>> don't think it has a JSON packing rule (the ASN.1 name for a 
>>>> transfer syntax). Other ASN.1 compilers do support JSON, but I don't 
>>>> know whether they target static-memory or embedded systems.
>>>>
>>>> The ESA-funded ASN1CC is here: <https://github.com/ttsiodras/asn1scc>.
>>>>
>>>> It supports BER (Basic encoding rules, a compact & fast binary 
>>>> format), PER (Packed Encoding Rules, a bit-packed binary format that 
>>>> will be slower but tighter), XER (XML Encoding Rules, you can 
>>>> imagine!), and ACN, where you get to define the encoding yourself.
>>>>
>>>> If you wish to serve the community as well as yourself, write JER, 
>>>> JSON Encoding Rules and submit it.
>>>>
>>>> A quick search finds a proposed standard: 
>>>> <https://www.obj-sys.com/docs/JSONEncodingRules.pdf> and a tool that 
>>>> analyses a JSON fragment and produces a proposed ASN.1 definition 
>>>> for the shape of the fragment <https://asn1.io/json2asn/>
>>>>
>>>> So there is existing work, and no doubt community support for more.
>>>> You could do a lot worse than start with ASN1CC.
>>>
>>> ASN.1 is interested. I will look at it more deeply.
>>>
>>> Just a simple question. Are optional fields possible in a message?
>>
>> Yes. And pretty-much everything else you might need in a static type 
>> system; sets of alternates with a discriminator (discriminated 
>> unions), arbitrary nesting of arrays of structures of arrays of 
>> structures, strings of many and various character sets and encodings, 
>> enumerations, numbers limited by range not storage size, etc.
>>
>> Not all ASN.1 implementations are equal. This one is targeted at 
>> systems that use no dynamic memory allocation, which is truly an 
>> excellent thing - but you probably can't do JSON like that. It's used 
>> for the majority of inter-module communications on ESA space missions, 
>> so it's pretty well tested and reliable too.
>>
>> The point is that the ASN.1 definitions are focussed on defining the 
>> values that can be meaningfully transferred, not the possible values 
>> of a set of representations. It's not fully powerful, but it's a lot 
>> better than most programming languages.
>>
>> I plan to emit ASN.1 from my Constellation Query Language tools at 
>> some stage this year, see <http://dataconstellation.com/ActiveFacts/>. 
>> CQL has a complete first-order logic constraint language, so it is 
>> even more powerful than ASN.1; and every feature (definition, 
>> constraint) is also expressible in controlled natural language and 
>> *compilable* from that language.
> 
> Incredibly, it seems there isn't any ASN.1 PER codec for 
> javascript/typescript (web-oriented) world. This limits the use to BER 
> only :-(

ASN1CC has support for two languages, so I assume that it is set up for 
multi-language support. If that has been done well (and I haven't 
checked but I'd be surprised if it hasn't) it should be a fairly 
straight-forward matter to add support for a third language. Probably 
easier than implementing a fixed JS/TS processor for your desired 
message schema. I daresay you'd make many people grateful for that.

Clifford Heath.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: Static JSON parser for embedded Clifford Heath <no.spam@please.net> - 2019-05-19 09:12 +1000
  Re: Static JSON parser for embedded Niklas Holsti <niklas.holsti@tidorum.invalid> - 2019-05-19 17:13 +0300
    Re: Static JSON parser for embedded Clifford Heath <no.spam@please.net> - 2019-05-20 09:25 +1000
  Re: Static JSON parser for embedded pozz <pozzugno@gmail.com> - 2019-06-06 11:12 +0200
    Re: Static JSON parser for embedded Clifford Heath <no.spam@please.net> - 2019-06-07 09:11 +1000
      Re: Static JSON parser for embedded pozz <pozzugno@gmail.com> - 2019-06-07 08:59 +0200
        Re: Static JSON parser for embedded Clifford Heath <no.spam@please.net> - 2019-06-12 09:41 +1000

csiph-web