BSDcan slides uploaded

[Jon Dama]

What exactly do you mean?  The way this is typically done is that you
write in ASN.1 the spec for your data interchange and feed it through a
compiler which generates (in a target language) the functions to encode
and decode the asn.1 + encoding rules stream.  The compiler essentially
knows how to make "one" generic encoder and decoder and customizes it
according to the spec.

This isn't much different from yacc, though imo, it's simpler.  Of course
there are several generations of ASN.1, different encoding rule options,
etc which complicate the situation.

Anyways, I don't understand your question exactly: do you mean to ask
about an ASN.1 compiler?

Fair enough about writing one parser per device class rather than two.
As I mentioned, ASN.1 is good approach to data exchange in bandwidth
constrained applications--I don't see any evidence that applies here.
So I agree with you essentially and was just trying to elaborate on the
actual meaning of your elliptic remark :-)

    -Jon

note: I do not in any way mean to encourage the idea that yacc should be
used to generate code inside the kernel.

On Thu, 19 May 2005, Poul-Henning Kamp wrote:

> In message <Pine.LNX.4.53.0505191238560.25801 at heave.ugcs.caltech.edu>, Jo=
n Dama
>  writes:
>
> >Though I have to take issue with Poul's opinion that writing many text
> >parsers is just as secure as writing one ASN.1 decoder, but then again I
> >wasn't at the talk so maybe Poul has one magic text parser to solve all =
of
> >the problems.
>
> Having written 2=BD ASN.1 parser myself, I couldn't help but wonder if
> you have "one magic ASN.1 parser to solve all of the problems" ?  :-)
>
> Seriously, one of the problems I'm pointing out is that since one end
> of the interface has a keyboard in 99.99% of the cases, the type
> determination might as well be postponed so that we only have to parse
> the input once, rather than two times.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetenc=
e.
>