🚀 go-pugleaf

In article <36800002@m.cs.uiuc.edu>, zweig@m.cs.uiuc.edu writes:
> [...]
>    Furthermore, this nonsense about "having to do the encoding at runtime" is
> laughable.
> [...]
> -Johnny The-OSI-Reference-Model-has-nothing-to-do-with-Implementation
> (#include <stddisclaimer.h>)

I agree completely.  ASN.1/BER are *representations*, not algorithms.  Once
"the bits are on the wire," so to speak, how they got there is immaterial,
as is what the receiving process does with them.

The same issue has come up in implementations of Sun RPC & XDR.  The
reference sources build everything on the fly, but a "real" implementation
should (I would argue) only do what it absolutely must on the fly.  In RPC
& XDR's case, this means that ultimately, XDR is just a way of specifying
packet formats (ASN.1 is similar, if more complex).  Granted, both ASN.1
and XDR allow automated tools to produce encoding and decoding routines
straight from a high-level description, but I would argue that (at least
in their current state) these should be considered prototyping aids more
than production aids.  If what's important is to get a prototype running
as quickly as possible, they are great.

This is not to say that, at some point, the automated tools may become
good enough to use in production environments.  The success of tools like
GLA (a lexical analyzer generator) and MetaWare's fast LR(1) parser
generator show that this sort of thing can be done well, but among the
reasons for their success is to precompute as much as possible in advance,
and to minimize the amount of processing that has to be done at runtime.

--
Amanda Walker
InterCon Systems Corporation
--
amanda@intercon.uu.net  |  ...!uunet!intercon!amanda