[Standards-JIG] PubSub Whiteboard
richard at dobson-i.net
Wed Jun 30 17:09:40 UTC 2004
> Surely, if we did pubsub before presence, we might have had a <pubsub/>
Yup a pubsub root stanza im sure would have solved a lot of these bandwidth
problems as they wouldnt have needed to be wrapped in the various ways they
are now, but creating a new top level element at this stage doesnt seem very
likely to me.
> 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'>
> <event xmlns='http://jabber.org/protocol/pubsub#event'>
> <items node='presence/ralphm'>
> <item id='current'>
> <presence xmlns='http://jabber.org/protocol/presence'>
> <text>Walked out a bit</text>
> They respectivily count 114 and 291 bytes without indentation.
Well over double the size to do the same thing, seems quite bloated to me
since it is doing the exact same thing, plus this is one of the foundation
parts of the protocol and one of the most frequently transmitted kinds of
stanza and so will massively increase the bandwidth use of servers and
clients, people with large rosters would be in real trouble well over
doubling the amount of bandwidth their presence broadcast consumes, not to
mention all the presences they will receive back into their client.
> 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.
Gzipping might help but it shouldnt really be needed as it shouldnt really
be so bloated to start with, plus implementing Gzip on servers would mean a
substantial jump in CPU requirements potentially, and on some devices such
as mobile phones where the low traffic requirements are most accute (people
paying by the kb) they might not be able to implement Gzip either because of
maximum file size contraints or a simple lack of CPU power.
> Also, the second has the benifit of carrying other presence related stuff
> in one stanza (location, mood, etc) without the drawbacks that the
> stanza has in this area.
Possibly but those things are not essential for the operation of the IM
system, presence by its very nature is, mobile clients could cut down the
bandwidth use by not supporting such extensions.
> Nevertheless I am glad with the current <presence/> stanza.
Good, me too.
> 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
> that MUC *is* a poor mans pubsub. I'm sure implementations of new
> would benifit from being able to reuse existing code from other pubsub
Im sure plenty of protocols will benefit lots from pubsub but when making
the decision to base things on pubsub research should really be done to make
sure using pubsub is not making things infinately more complex just for the
sake of using it. Im not saying pubsub is rubbish or useless just that as
with anything it is far more suited to some tasks than others, IMO something
like MUC wouldnt have benefited really from being implemented using pubsub
since it is so complex and consists of so many different things together and
trying to implement it on pubsub would have made it even more complex, e.g.
when sending messages to a room IMO it is far cleaner the way MUC operates
now, but if it was done with pubsub the messages would be re-wrapped again
in a second message before being sent along which IMO is unnecessarly
More information about the Standards