on 8/24/2003 1:53 AM Rob Austein wrote:
I've used ASN.1 compiler technology for a project that included an
H.323-related frob, and ended up wishing I hadn't. Can you say more
than 2MB just for the ASN.1 PER encoder/decoder on a box with an 8MB
flash chip? (For comparision, the embedded Linux kernel on this same
box was quite a bit less than 1MB.) I knew you could. No doubt we
could have gotten a smaller implementation if we'd been willing to
throw serious money at it, but H.323 wasn't even the main point of the
quick-n-dirty = bloat is a universal. I've seen rfc822 parsers that were
nearly as large for example. As far as that goes, moving bloat around
within a layer doesn't seem to matter much in the end, and ASN.1 parser
bloat is just as bad as XML or 822 or [...] parser bloat.
The question of where compression should occur is a good one. The usual
suspects are the application or the data-link layers, but I'm not sure
there are overwhelmingly compelling arguments for either, or that equally
compelling arguments couldn't be made for transport or network layer
compression for that matter.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/