[Standards-JIG] PubSub efficiency was XMPP bandwidth compression
Fletcher, Boyd C. J9C534
Boyd.Fletcher at je.jfcom.mil
Tue Jul 6 23:43:02 UTC 2004
> -----Original Message-----
> From: standards-jig-bounces at jabber.org
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of Bob Wyman
> Sent: Monday, July 05, 2004 2:45 PM
> To: jean-louis.seguineau at antepo.com; 'Jabber protocol discussion list'
> Subject: RE: [Standards-JIG] PubSub efficiency was XMPP
> bandwidth compression
> In any case, I strongly feel that this issue should not
> be dealt with casually or quickly. I'm very much afraid that
> people will, for instance, just do the obvious thing and
> write standards that call for gzip compression. It turns out
> that while this is an "obvious" solution to the "size"
> problem, it is NOT the correct solution if you are also
> concerned with speed of parsing, dealing with streaming data,
> implementing routers, etc. If nothing else, we can note that
> none of the people who have implemented alternatives to XML
> have found that gzip was sufficiently useful to solve the problem...
My concern here is that we are combining discussion regarding efficient parsing with efficient networking. Though they can be related, they aren't necessarily. For the bandwidth problem I've been trying to describe parsing isn't a problem, delivering the bits the to user is. I think it would simpler for all if we separate the discussion into two parts: compressing an XMPP stream and efficient parsing of XMPP.
> Currently, few people have the problems that XML
> alternatives address. We should avoid making quick decisions
> and implementing solutions before the problem space is well
> understood. I believe that now is *not* the time to consider
> XML alternatives in the XMPP space -- yet, we should be doing
> what we can to understand the issues and preparing to deal
> with them in the future.
> Personally, I think the eventual solution to this
> problem will involve very strong statements that XML is now
> and will remain the default encoding for XMPP but that there
> would be stream initiation protocol extensions to allow the
> negotiation of support for alternatives. What those
> alternatives are should be a subject of a "battle in the
> marketplace" -- not quick decisions made with insufficient
> data and experience.
I agree with that approach, however I think we need to work out a solution for compressing XMPP packets sooner rather than later.
> bob wyman
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards