From owner-freebsd-current@FreeBSD.ORG Fri May 20 09:09:45 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EC7216A4CE for ; Fri, 20 May 2005 09:09:45 +0000 (GMT) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1534A43D3F for ; Fri, 20 May 2005 09:09:44 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 11:09:42 +0200 Date: Fri, 20 May 2005 11:09:42 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Jon Dama In-Reply-To: Message-ID: <20050520105956.Q73700@beagle.kn.op.dlr.de> References: <22364.1116533237@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2112695462-1116580182=:73700" X-OriginalArrivalTime: 20 May 2005 09:09:42.0419 (UTC) FILETIME=[A89B7E30:01C55D1B] cc: Poul-Henning Kamp cc: Karel Miklav cc: current@freebsd.org Subject: Re: BSDcan slides uploaded X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 09:09:45 -0000 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 ,= 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--