Dave, take a look at http://www.agiledelta.com/w3c_binary_xml_proposal.html and http://www.idealliance.org/papers/xml02/dx_xml02/papers/06-02-04/06-02-04.pd 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. boyd On 2/14/08 3:39 PM, "Dave Cridland" <[EMAIL PROTECTED]> 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 > required. > > >> > Anything else? > > Beer, obviously. > > Dave. > -- > Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >
