[Standards] Proposed XMPP Extension: Stream Compression with Efficient XML Interchange

juha.p.hartikainen at nokia.com juha.p.hartikainen at nokia.com
Tue Feb 19 09:02:48 UTC 2008


Is there any calculations available for exi and zlib?


>-----Original Message-----
>From: standards-bounces at xmpp.org 
>[mailto:standards-bounces at xmpp.org] On Behalf Of ext Dave Cridland
>Sent: 18 February, 2008 15:17
>To: XMPP Extension Discussion List
>Subject: Re: [Standards] Proposed XMPP Extension: Stream 
>Compression with Efficient XML Interchange
>On Sat Feb 16 10:18:37 2008, Fabio Forno wrote:
>> Did some homework about EXI.
>As did I - not that I'm claiming expertise quite yet. Some 
>random notes follow.
>I basically agree that we don't want to be doing this as 
>XEP-0138, for a number of reasons, including it being an 
>additional round-trip, but it works as a way of doing some 
>What's currently concerning me is that a single schemaID 
>option may be present, which indicates the single schema 
>you've used for encoding.
>Currently, we have no such single schema, and in the absence 
>of such a schema, my understanding is that the bulk of the 
>performance of EXI is down to its usage of DEFLATE - thus 
>somewhat contradicting those people who've been telling me 
>that DEFLATE is a Bad Thing for mobile devices, but EXI is 
>fantastic. Ho hum.
>The schemaID is non-restrictive - that is, that use of a 
>schemaID wouldn't restrict usage of other schemas. So 
>specifying bling use of EXI is insufficient for our purposes - 
>we need to define a single schema which represents the overall 
>schema used for the stream.
>On top of that, the more accurate that schema is, the better 
>compression will be achieved - out performing DEFLATE by a 
>reasonable margin. This suggests that the more we put into our 
>master schema, the better - so we probably want more than one 
>of them, to allow for different deployment types to handle 
>their cases optimally.
>So it seems to me that if we were using EXI in XEP-0138, a 
>single "exi" algorithm isn't sufficient to grant 
>interoperability. Instead, we need a method for negotiating 
>schemaIDs, codecs, and the various other random options. In 
>particular, we probably want the precompression option 
>available, for the rather odd case of doing DEFLATE in TLS, 
>but EXI in XEP-0138.
>It occurs to me that for certain schemas particularly heavy in 
>markup, like SVG whiteboarding, the compression potential is 
>pretty high, but for quite a few typical uses of XMPP - like 
>IM itself - the bulk of the compression will be down to 
>DEFLATE anyway, suggesting that doing EXI in these cases isn't 
>worthwhile - although I may be wrong here.
>Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
>Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list