On Fri, 20 May 2005, Jon Dama wrote: JD> JD>What exactly do you mean? The way this is typically done is that you JD>write in ASN.1 the spec for your data interchange and feed it through a JD>compiler which generates (in a target language) the functions to encode JD>and decode the asn.1 + encoding rules stream. The compiler essentially JD>knows how to make "one" generic encoder and decoder and customizes it JD>according to the spec. JD> JD>This isn't much different from yacc, though imo, it's simpler. Of course JD>there are several generations of ASN.1, different encoding rule options, JD>etc which complicate the situation. JD> JD>Anyways, I don't understand your question exactly: do you mean to ask JD>about an ASN.1 compiler? JD> JD>Fair enough about writing one parser per device class rather than two. JD>As I mentioned, ASN.1 is good approach to data exchange in bandwidth JD>constrained applications--I don't see any evidence that applies here. JD>So I agree with you essentially and was just trying to elaborate on the JD>actual meaning of your elliptic remark :-) I think this is OT with regard to the initial topic but anyway: First time I hear someone to say this. ASN.1 is horrible from the syntax point of view: it was obviously designed by people having no clue in language design. It is even worse than Algol with it's user changeable syntax. I wonder if there are really ASN.1 compilers that handle the full language. BER is horrible and by no means bandwidth effective - in most cases you don't need the type tags and length bytes, because you just know what should be there (for a prominent example look at SNMP). It is horrible to decode/encode for both software and hardware (who needs 3 or 7 or 11 byte integers anyway?) Although it allows you to decode a data stream that you don't know anything about - what's the use for this? XDR is much more dense and bandwidth effective. harti JD> JD> -Jon JD> JD>note: I do not in any way mean to encourage the idea that yacc should be JD>used to generate code inside the kernel. JD> JD>On Thu, 19 May 2005, Poul-Henning Kamp wrote: JD> JD>> In message <Pine.LNX.4.53.0505191238560.25801_at_heave.ugcs.caltech.edu>, Jon Dama JD>> writes: JD>> JD>> >Though I have to take issue with Poul's opinion that writing many text JD>> >parsers is just as secure as writing one ASN.1 decoder, but then again I JD>> >wasn't at the talk so maybe Poul has one magic text parser to solve all of JD>> >the problems. JD>> JD>> Having written 2½ ASN.1 parser myself, I couldn't help but wonder if JD>> you have "one magic ASN.1 parser to solve all of the problems" ? :-) JD>> JD>> Seriously, one of the problems I'm pointing out is that since one end JD>> of the interface has a keyboard in 99.99% of the cases, the type JD>> determination might as well be postponed so that we only have to parse JD>> the input once, rather than two times. JD>> JD>> -- JD>> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 JD>> phk_at_FreeBSD.ORG | TCP/IP since RFC 956 JD>> FreeBSD committer | BSD since 4.3-tahoe JD>> Never attribute to malice what can adequately be explained by incompetence. JD>> JD>_______________________________________________ JD>freebsd-current_at_freebsd.org mailing list JD>http://lists.freebsd.org/mailman/listinfo/freebsd-current JD>To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" JD> JD> JD>Received on Fri May 20 2005 - 07:09:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:34 UTC