Re: [saag] draft-hallambaker-mesh-udf-02

[Nico Williams <[e-mail]>]

On Mon, Apr 22, 2019 at 04:22:45PM -0400, Phillip Hallam-Baker wrote:
> Another possibility is that people like the technology I am applying but
> would prefer to look at extending PCKS#7/CMS and retrofitting these ideas
> to other legacy protocols. I think it best to develop the capabilities
> first and then look to how they might be retrofitted though. Conversion to
> ASN.1 would require a sponsor willing to fund the work.

It's all the same to me.  However, I would on balance prefer that a) no
new _encodings_ be created without b) a great deal of knowledge of what
came before.

I've been toying with this idea:

 - adapt the Heimdal ASN.1 compiler to output a JSON representation of
   the input module(s),

 - then use jq to transform that in various ways,

 - and lastly, use jq to generate codecs for the [transformed] module
   representations.

Interesting transformations would be to, e.g.,

 - apply code generation controls (e.g., "this INTEGER should be
   represented as a uint32_t in C, and that one as an in64_t"),

 - to add private structure fields for application use (for keeping
   state; this has been a significant driver for hand-coding of codecs).

Why jq?  Well, because it's a very pithy and accessible, functional,
high-level programming language specifically designed for working with
JSON data.  I would prefer to do the whole thing in Haskell, but I'm not
yet fluent in Haskell, and anyways, it's a less accessible language.

Of course, too, there's the fact that I'm one of the maintainers of jq,
which means I'm very familiar with it and productive in it.  But I have
a feeling that once I have a sample code generator for such a thing it
will be very easy to create new backends out of it -- in fact, that
would be a goal.

Nico
--