[Standards-JIG] XMPP bandwidth compression

Fletcher, Boyd C. J9C534 Boyd.Fletcher at je.jfcom.mil
Fri Jul 2 02:29:08 UTC 2004


maybe I'm not understanding Fast Infosets but it seems to me that

1) largely ignores the content of message (which sometimes can be a good thing for IBB or Signed Content) but overall I suspect that's a bad idea.

2) it doesn't handle namespace or attribute compression (just does duplicate substitution). Since JIDs and Namespaces make up a significant portion of the XMPP traffic this would seem like a rather significant problem unless we consider an entire XMPP stream as a single document.

3) It would seem to be me slower (or more expensive) to covert from XML on the client to FI and do some content compression method before tranporting then reverse the process on the server, than to just do some type of block compression for the entire message. 

4) that the real advantage of FI is in fast processing of the document not in the compression.

Though I was wrong about the requirement to know the schema before hand, infoset's approach uses quite a bit more bandwidth than the approach of knowing the schema before hand. Also, the way Infoset appears to implement its optimizations appears to have the biggest impact on documents that have lots of identical and long (greater 8 characters) strings/tags. 

So if it was used for XMPP, would we consider a single XMPP stream as a single document?
We the small tag sizes of jabber protocol would we really gain that much compared to a regular block compression like gzip?


boyd 

> -----Original Message-----
> From: standards-jig-bounces at jabber.org 
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of 
> Fabrice Desré - France Telecom R&D/MAPS/AST
> Sent: Thursday, July 01, 2004 3:36 AM
> To: Jabber protocol discussion list
> Subject: Re: [Standards-JIG] XMPP bandwidth compression
> 
> Fletcher, Boyd C. J9C534 wrote:
> > almost forgot, one of the problems with table based lookup 
> compression for XML is that advance knowledge of the xml 
> schema is required. this isn't practical in XMPP since the 
> server generally has little knowledge of the schema beyond 
> the basic tags and sending the schema at the start of the 
> transmission is too costly.
> 
>   This is just not true. You cant have a dynamic table-based 
> compression scheme for XML that is not schema aware. Look at 
> Fast Infoset for instance 
> (http://java.sun.com/developer/technicalArticles/xml/fastinfoset/)
> 
> 	Fabrice
> --
> Fabrice Desré
> France Télécom R&D/MAPS/AST
> Tél: +(33) (0)2 96 05 31 43
> Fax: +(33) (0)2 96 05 39 45
> http://www.francetelecom.com/rd
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig
> 
> 



More information about the Standards mailing list