[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: ASN.1

• From: "Hutchison, Nigel" <nwoh@s...>
• To: xml-dev@i...
• Date: Fri, 16 Apr 1999 16:55:44 +0200

-----Original Message-----
From:   Mike Spreitzer [SMTP:spreitze@p...]
Sent:   Friday, April 16, 1999 3:31 PM
To:     'Hutchison, Nigel'; xml-dev@i...
Subject:        RE: ASN.1

Nigel Hutchison wrote: [[
I would have thought that the best way of dealing with this issue is to use
a "pleasant" syntax which was easy to  process and implement another layer
to compress the payload for transmission.
]]

Best in some contexts, but not all.  The compression layer has runtime
costs, in both code and memory footprint, and processing time.  In some
contexts (e.g., very resource-constrained items like cell phones and Palm
Pilots), these costs can be significant.
[Nigel Hutchison]   I had some experience recently in trying to devise a RPC XML DTD which was nice and compact. So I did also sorts of tricks with short tag names, repetition conventions etc etc. This had the effect of iincreasing the creation and parsing code significantly. I imagine that there is a considerable footprint and CPU penalty is this optimisation. II also found the prospect of testing and debugging this quite daunting.     I then realised that when I send and receive XML documents via my analogue modem they are effectively compressed and decompressed by the hardware - so I was wasting my time (in that scenario at least). I would have thought that all cellphones would do compression and decompression when they send and receive data - is that not so?

 I also found out that Mainframes have firmware supporting LZ compression these days.
Regards

Nigel Hutchison
 Mike

• Prev by Date: RE: ASN.1
• Next by Date: Re: ASN.1
• Previous by thread: RE: ASN.1
• Next by thread: ANNOUNCE: Python/XML release 0.5.1
• Index(es):
  • Date
  • Thread