[Standards-JIG] proto-JEP: Smart Presence Distribution

Dave Cridland dave at cridland.net
Thu Jun 1 14:29:19 UTC 2006

On Thu Jun  1 14:38:10 2006, Carlo v. Loesch wrote:
> Dave Cridland typeth:
> | In general, introducing increased framing means that the protocol 
> | stream will be larger, post-compression, as far as I've found. | 
> Admittedly, this is just a very strong hunch backed up by a few | 
> examples.
> Hmm.. are you talking about a protocol optimized for framing, or are
> you talking about a method to apply framing on top of XMPP? I may 
> have
> missed some discussion or JEPs about that.
No, this is not specific to XMPP.

> | The other assertion - that parsing it takes an increased amount 
> of | time - is debatable, I'd want to see figures on that before 
> accepting | it.
> It's technical, when you know how much data is coming your way, you
> can instruct your libs/kernel to just put the next XY octets 
> straight
> into a buffer, whereas with XML you have to parse everything because
> you never know *when* the final closing tag comes your way.
Oh, you think *that* is a significant issue? In general, I think XML 
parsers are sufficiently fast it's a non-issue - I agree it'll 
increase the CPU cost of parsing, but in percentage terms, I think 
it's negligable.

The trouble is that framing using a prefixed octet count also means 
you have to assemble each frame in memory before transmission, which 
can yield less flexibility in some environments. You can avoid that 
with a chunking mechanism, of course, but that in turn increases the 
octet count.

I'm afraid that like many things in protocol syntax design, it 
becomes a matter of personal taste and trade-offs, and it's really 
not worth spending any time over for the most part.

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