[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: going back to stone axes


> The main problem with ASN.1, for my purposes, is that it isn't close
> enough to any real target programming language's data structure
> definition constructs to invoke the programmer's training -- looking
> ahead to packing, parsing and using structures and wanting to do so
> efficiently and simply.

You are diving down to the bits and bytes again.  There is no need to. If
you keep in mind that SEQUENCE equates to a C struct, SEQUENCE OF equates
to a linked list or array, and CHOICE equates to a union with a 
discriminant, and use subtype constraints where possible there is little
to concern yourself about.  And for simplicity in reading and writing 
ASN.1, avoid using tags if you can, and use AUTOMATIC TAGS instead; it 
results in the ASN.1 being easier to read and you don't get yourself into
trouble writing ASN.1 that later turns out to have tag conflicts, double 
tagging or the likes if the encoding rules in use are BER or DER.

There really is nothing in ASN.1 that prevents efficient and simple
parsing and usage of structures.  Indeed, if you look at Christian
Huitema's Lightweight Encoding Rules you see that it is possible to
make it so untra-simple that all that you need do is overlay the
encoded byte stream with the C mapping, convert all pointers from
offsets to actual memory address, convert integer values from whatever
to your endian order if needed, and you are done.  How efficient and
simple it is to encode data is a function of the encoding rules, not ASN.1.