Date: Fri, 20 May 2005 11:09:42 +0200 (CEST) From: Harti Brandt <hartmut.brandt@dlr.de> To: Jon Dama <jd@ugcs.caltech.edu> Cc: current@freebsd.org Subject: Re: BSDcan slides uploaded Message-ID: <20050520105956.Q73700@beagle.kn.op.dlr.de> In-Reply-To: <Pine.LNX.4.53.0505200116570.7686@heave.ugcs.caltech.edu> References: <22364.1116533237@critter.freebsd.dk> <Pine.LNX.4.53.0505200116570.7686@heave.ugcs.caltech.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2112695462-1116580182=:73700 Content-Type: TEXT/PLAIN; charset=koi8-r Content-Transfer-Encoding: QUOTED-PRINTABLE 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 cours= e 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=20 point of view: it was obviously designed by people having no clue in=20 language design. It is even worse than Algol with it's user changeable=20 syntax. I wonder if there are really ASN.1 compilers that handle the full= =20 language. BER is horrible and by no means bandwidth effective - in most=20 cases you don't need the type tags and length bytes, because you just know= =20 what should be there (for a prominent example look at SNMP). It is=20 horrible to decode/encode for both software and hardware (who needs 3 or 7= =20 or 11 byte integers anyway?) Although it allows you to decode a data=20 stream that you don't know anything about - what's the use for this? XDR=20 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@heave.ugcs.caltech.edu>,= Jon Dama JD>> writes: JD>> JD>> >Though I have to take issue with Poul's opinion that writing many tex= t JD>> >parsers is just as secure as writing one ASN.1 decoder, but then agai= n I JD>> >wasn't at the talk so maybe Poul has one magic text parser to solve a= ll of JD>> >the problems. JD>> JD>> Having written 2=BD 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@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 incompet= ence. JD>> JD>_______________________________________________ JD>freebsd-current@freebsd.org mailing list JD>http://lists.freebsd.org/mailman/listinfo/freebsd-current JD>To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" JD> JD> JD> --0-2112695462-1116580182=:73700--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050520105956.Q73700>