[Standards] mobile optimizations (was: Re: Google Andro ï d SDK not XMPP compliant ?)
boyd.fletcher at je.jfcom.mil
Thu Feb 14 22:06:19 UTC 2008
take a look at http://www.agiledelta.com/w3c_binary_xml_proposal.html and
f. The W3C spec is based on Agile Delta¹s EfficientXML. the data I have seen
on EfficientXML indicate that it many times more efficient on than Zip.
1362 byte message strongly typed
WinZip 3.13 times smaller than original
EfficientXML 75.67 times smaller than original
980 byte message loosely type
WinZip 1.6 times smaller than original
Efficient XML 8.45 times smaller than original
21437 byte message
Winzip 6 times smaller
Efficient XML 33 times smaller
I have other data for large message sizes if interested. Unfortunately I
can¹t provide the raw data or the messages used. But group that did the
study tested the messages with WinZip, MPEG-7+BIM, Xmill, Efficient XML,
ASN.1 PER, and WBXML-like. Efficient XML beat them all by a large margin.
Binary XML will help out in two significant errors where XMPP is used:
1. can be a significant reduce in b/w used. Which can have a big impact on
the performance of a server
2. faster processing in the chat server. reading XML is expensive. most of
the binary XML formats were designed to be not only much smaller in size but
also much less CPU intensive to process. This should in theory dramatically
improve the scalability of a given XMPP server.
On 2/14/08 3:39 PM, "Dave Cridland" <dave at cridland.net> wrote:
> On Thu Feb 14 20:08:53 2008, Peter Saint-Andre wrote:
>> > Here's a list of things we might talk about:
>> > 1. Recommendations regarding when to use the TCP binding and when
>> > to use
>> > the HTTP binding (BOSH).
>> > 2. Compression via TLS or XEP-0138 (use it!). Also binary XML as a
>> > compression mechanism.
> I've never been all that convinced about binary XML forms. They work
> to a degree with the highly fixed XML in, for example, SyncML, and
> they're pretty good at compressing individual stanza-like objects
> over SMS for things like OMA EMN (Email Message Notification, or
> something - I've long since forgotten what these acronyms stand for),
> but for long-running streams I'm under the impression that studies
> show it'll be outperformed.
> So if you're a big fan of Binary XML formats, please bring along your
> figures. :-)
>> > 3. Fast reconnect to avoid TLS+SASL+resource-binding packets.
> Lots of work from mobile email (ie, Lemonade) is transferrable here.
> It'd be really nice if Tony Finch was coming, since he could talk us
> through QTLS and QUICKSTART - they're SMTP fast startup work he did a
> while back. Very interesting, but didn't make it into the Lemonade
> Profile itself.
>> > 4. ETags for roster-get (see XEP-0150, let's resurrect that).
> (Om. Looks quite ugly, IMHO. I'll do a counter-proposal)
>> > 5. Advisability of presence-only connections (no roster-get, just
>> > send
>> > presence and whatever you receive is nice).
> If you can optimize the roster fetch sufficiently, this really isn't
>> > Anything else?
> Beer, obviously.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards