[Standards-JIG] PubSub Whiteboard

Richard Dobson richard at dobson-i.net
Wed Jun 30 15:18:07 UTC 2004


> Nolan Eakins wrote:
> > Basically I see no need for whiteboarding over PubSub. Unless of
> > course MUC is going to be changed so it runs on top of PubSub, but
> > I see no need for that either even though MUC is an extremely
> > basic publish-subscribe service.
> As you said: "MUC is an extremely basic publish-subscribe service."
> The key is "extremely basic." You should also have added
> "application-specific" in that MUC only incorporates those elements of a
> publish/subscribe service that are specifically required for MUC.
> For some whiteboard requirements, you need more and different things
> than can be squeezed into MUC and, if you try to extend MUC to handle what
> whiteboarding needs but MUC doesn't, what you're doing is moving MUC
towards
> being a full pubsub protocol. When creating a new Jabber/XMPP based
protocol
> or application that requires publish/subscribe services, the correct and
> logical starting point is JEP-0060 -- which is probably what MUC would
have
> done if JEP-0060 had existed before MUC was defined.
> MUC should be used for MUC and only MUC. It should not be used as a
> "poor man's pubsub", nor should it be pushed to become a more general
> publish/subscribe service in the future. Note: The same can be said about
> Presence... There is little to Presence other than a stripped down pubsub
> system.
> I think that if the pubsub protocol had existed before MUC and
> Presence, neither of them would have been created as distinct protocols --
> they would just be profiles on JEP-0060. But, that is hindsight...

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.

Richard




More information about the Standards mailing list