[Standards-JIG] XMPP bandwidth compression
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
>> 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
>> 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
> 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