[Standards-JIG] XMPP bandwidth compression

Tijl Houtbeckers thoutbeckers at splendo.com
Thu Jul 1 17:44:06 UTC 2004


On Thu, 1 Jul 2004 12:00:17 -0400, Bob Wyman <bob at wyman.us> wrote:

> 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.

It's true fast infoset isn't a compression system in the traditional  
sense. It does however take a certain type of data and tries to make it  
faster and smaller. It also uses some techniques simulair to traditional  
compression methods, it just applies them in a smarter way. Though I admit  
I have no experience with fast-infoset itself, this does usually mean that  
applying traditional compression to it has less effect.

Fast-infoset however is a compromise between size reduction and speed of  
parsing, so there is probably still something to gain by applying  
traditional compression afterwards if it's mostly size that matters to you.

> 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.

You could still solve both in the same solution. The problem right now is  
that XMPP XML-streams are just opened without any negotiation wich method  
to use to transport them. (The only thing both sides can do is detect wich  
encoding either side is trying to use, there isn't a way to find out wich  
are and aren't supported either).

You could do a HTTP style opening of the XML-stream, let the client know  
which methods it supports and which it prefers using MIME types (for  
example "application/xmpp+xml", "application/xmpp+fastinfoset",  
"application/xmpp+xml+gzip", "application/xmpp+fastinfoset+gzip"), then  
let the server pick on and return it. The same could be done for charsets.  
Then you have a normal XML stream like any other.



More information about the Standards mailing list