[Standards-JIG] PubSub Whiteboard
jabber.org at ralphm.ik.nu
Wed Jun 30 16:02:33 UTC 2004
On Wed, Jun 30, 2004 at 04:18:07PM +0100, Richard Dobson wrote:
> I would highly doubt that JEP-0060 in its current form would have been used
> for presence, it is far too complicated and creates masses more unnecessary
> data for it to be really useful for presence, as presence is such a highly
> used protocol and is essential for mobile devices for which every byte
> counts, the byte count down must be kept to a minimum, IMO because pubsub
> creates so much traffic in its current form even for simple things it would
> be unusable for presence, hence why it would probably have ended up the way
> it is now with a purpose built highly optimised protocol, dito for MUC, MUC
> uses so many complex and application specific concepts that it would
> probably not have been worthwhile baseing MUC on pubsub as it would make it
> far more complex to achieve the same functionality for little real value.
> This is one thing I think we need to be mindful of when creating new
> protocols that might be based on pubsub, it needs to be examined if the
> benefits of baseing a protocol on the pubsub framework outweigh the
> downsides (increased complexity, increated network traffic), and if a more
> application specific solution might be a better choice.
Surely, if we did pubsub before presence, we might have had a <pubsub/> root
stanza. Surely, the <presence/> element is very short, but notifications by
JEP-0060 are not that big. A presence stanza like:
<presence from='ralphm at ik.nu' to='user at example.com'>
<status>Walked out a bit</status>
Would have a JEP-0060 equivalent like:
<message from='jsm.ik.nu' to='user at example.com'>
<text>Walked out a bit</text>
They respectivily count 114 and 291 bytes without indentation.
Gzipping just these stanzas reveals 116 vs. 194 bytes, and having more
of them in one session would drive the two numbers closer to eachother.
Also, the second has the benifit of carrying other presence related stuff
in one stanza (location, mood, etc) without the drawbacks that the <presence/>
stanza has in this area.
Nevertheless I am glad with the current <presence/> stanza.
I suspect implementations of the service site of MUC and pubsub have much
in common in terms of code. This is unfortunate, and caused by the very fact
that MUC *is* a poor mans pubsub. I'm sure implementations of new protocols
would benifit from being able to reuse existing code from other pubsub
More information about the Standards