Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #28659
| 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.
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
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