[Standards-JIG] Re: MUC traffic issues

Jay Carlson nop at mitre.org
Mon Feb 20 05:13:35 UTC 2006

You don't even need real stream compression for this to pay off.  SIMP used
non-XML stanza framing (the oh-so-popular record length in network byte
order).  A quick experiment resulted in a big win in zlib compression of
individual stanzas, and an even bigger win in compression of stanzas given
just the *previous* stanza as a zlib dictionary preload.  Unsurprisingly,
the current stanza is statistically likely to contain a lot of the same
octet patterns as the previous one....

(Not to mention the misery of using XML as a framing mechanism... whoops, I
just did.)

(Maybe I shouldn't be unnecessarily antagonizing people after midnight local
time on a Sunday.  :-)


> -----Original Message-----
> From: standards-jig-bounces at jabber.org [mailto:standards-jig-
> bounces at jabber.org] On Behalf Of Trejkaz
> Sent: Sunday, February 19, 2006 11:54 PM
> To: Jabber protocol discussion list
> Subject: Re: [Standards-JIG] Re: MUC traffic issues
> Ulrich Staudinger wrote:
> > Well, that does not work good for large chat rooms, the delivered
> > messages would become ULTRA big. I still think the xmpp protocol is very
> > verbose and a diet could be good for it, but that's my personal opinion.
> > ( I still like the approach to slim out "iq" by "i", "presence" by "p"
> > and "message" by "m"), but don't listen to me on the last topic.
> I'm inclined not to care much about compressing "presence" to "p" as
> long as people are still declaring namespaces at the point of use
> instead of putting some of the more common ones up on the root element.
> I think some kind of XML macros would probably pay off faster anyway.
> (Not to mention using real compression... whoops, I just did.)
> TX

More information about the Standards mailing list