[Standards-JIG] XMPP bandwidth compression

Bob Wyman bob at wyman.us
Thu Jul 1 16:00:17 UTC 2004

Tijl Houtbeckers wrote:
> (fast infoset for example seems to *increase* throughput of SAX parsing of
> XML documents), and yes; they beat gzip on size (which will always be
> slower I'd think, gzip will have to uncompress first, then do regular XML 
> parsing).
> So if some framework for compression will be made, it should be generic 
> to allow for different methods.

	It should be recognized that use of Fast Infoset isn't really the
same, conceptually, as using gzip or any other compression method. Rather
than being a "compression" method, Fast Infoset is simply an alternative
encoding of the XML Infoset which results in encoded objects which are
smaller and faster to parse than what you get with traditional text-based
XML encodings of the Infoset. The use of an alternative encoding is very
different from using a "compression" system. A compression framework would,
I think, be appropriate for cases where people needed to do "two-phase"
processing (Phase 1: Decompress, Phase 2: Parse). Thus, you might use a
compression framework with either XML or Fast Infoset as your encoding. 
	Fast Infoset is not a compression technology. It is simply a more
compact and faster encoding method for XML Infosets. It really doesn't make
sense to talk about compression frameworks when discussing Fast Infoset -
the two issues are orthogonal. I think, however, that we'll find that by
using Fast Infoset in size/speed sensitive systems will reduce drastically
the need to do explicit compression. For many applications, the efficiency
of Fast Infoset will be sufficient -- without additional compression.

		bob wyman

More information about the Standards mailing list