Seems to me you'd probably save a lot more, in aggregate, by encoding the tags in a standard notation (i.e. the ASN.1 comment I made before) rather than the payload. A token-y, session long (or server global) scheme would be a lot lower processing overhead and save a ton of bandwidth.
XML was never meant to be bandwidth sensitive, in fact has almost the opposite as a goal. But it's still great for what we're using it for in general. A transparent (servers would support both) optimization only would make sense. -----Original Message----- From: Julian Missig [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 5:31 PM To: [EMAIL PROTECTED] Subject: Re: [JDEV] GZipping Jabber Messages It's not really defining a binary transport layer, it's just gzipping the stream. They're looking for something less processor-intensive than SSL, I imagine. You can argue the merits of it when/if it comes up as an official extension/replacement for bits of Jabber via a JEP. Until then, unless you have a better suggestion, I think they're pretty much free to play with want they want. Maybe they'll figure out something that would be worth writing up a JEP for. Maybe not. Official Jabber won't contain it until they write up a JEP, so there's no need to worry. Julian -- email: [EMAIL PROTECTED] jabber:[EMAIL PROTECTED] Michael F Lin wrote: > Is this in parallel to how SSL works with encryption or does SSL do > compression already? If so then lets just use SSL. If not, then I find the > idea of defining our own binary transport layer a bit unsettling. We're > talking XML, we should be above all that ;-) > > -Mike > > > > > Julian Missig > <[EMAIL PROTECTED] To: [EMAIL PROTECTED] > g> cc: > Sent by: Subject: Re: [JDEV] GZipping Jabber Messages > jdev-admin@jabber > .org > > > 01/04/2002 04:57 > PM > Please respond to > jdev > > > > > > Nah, I think they're talking about gzipping all of the data, sending it, > and ungzipping before sending it to the XML parser on the other side, > just like SSL works. > > Julian > -- > email: [EMAIL PROTECTED] > jabber:[EMAIL PROTECTED] > > Michael F Lin wrote: > > > Keep in mind that the gzip data would have to be base64 coded, which > > would increase its size by 33%. So you can run the statistics and > > figure out how long your payloads have to be to get better than 33% > > compression ratios with gzip, but I imagine it is quite long > > relative to the average since of a Jabber packet > > (message/presence/iq). > > > > -Mike > > > > > > > > > > Adam Theo > > <adamtheo@theoret To: jdev <[EMAIL PROTECTED]> > > ic.com> cc: > > Sent by: Subject: [JDEV] GZipping Jabber Messages > > jdev-admin@jabber > > .org > > > > > > > > 01/04/2002 03:32 > > PM > > Please respond to > > jdev > > > > > > > > > > > > > > Hi, all. There's a good discussion going on over at the DotGNU > > Developer list about gzip'ing the XML that is transmitted around on > > the DotGNU platform. > > > > Was wondering if it would be possible to incorporate the same thing > > for future versions of the Jabber server? Is it feasible, anyway? > > They are saying the trade-offs for extra resource consumption would > > not be bad at all if designed into the server properly, and would > > reduce bandwidth very dramatically (like by 80%, i think). This > > would be useful for high-volume servers with enough processing > > power, i think... _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
