Re: BSDcan slides uploaded

From: Harti Brandt <hartmut.brandt_at_dlr.de>
Date: Fri, 20 May 2005 11:09:42 +0200 (CEST)
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