[Standards-JIG] RE: PubSub Whiteboard

Nolan Eakins sneakin at semanticgap.com
Fri Jul 2 08:25:32 UTC 2004

This reply actually justified the use of pubsub in whiteboarding pretty well
for me. It didn't occur to me that the current state of the whiteboard
would have to be sent when someone joined. I guess my limited testing
didn't call for that. Though I'm sure a modification to get a complete chat
history through MUC could be done, I'm pretty sure that it would
inefficient. Especially since only the current state would be needed,
additions plus updates minus deletes.

Now I'm curious, and wanting to get my feet wet. Both with pubsub and a
proper Jabber whiteboard. Where can I find out more about the wb described

Nolan Eakins

Fletcher, Boyd C. J9C534 wrote:
> We are working on a spec for Scalable Vector Graphics based whiteboarding
> over Jabber. We are using PubSub for our token passing and as a store for
> whiteboards. the problem with using MUC is there is no reliable way to get
> the current status of the whiteboard (wb). Originally we had thought about
> sending all the wb commands over a separate chat room. When a user enters
> the conference, they would get a dump of all the wb commands. the problem
> with this approach is (1) the server must maintain the entire history of
> the whiteboard and (2) the user must download the entire history of the
> whiteboard. An alternative would be for a user to ask another user the
> current wb status and have it sent to them, this is not a very reliable
> approach. What we decided to do is send all adds/deletes/updates to the
> whiteboard's pubsub service, so when a user enters a chat room, his client
> pulls the configuration for the MUC to see if it supports multimedia (note
> this is a slight change to the MUC config) and if it does what is the JID
> of the root pubsub node for the room. The room's pubsub node contains the
> current multimedia capabilites for the room including audio support,
> application casting support, video, whiteboards, presentations, etc... In
> the case of whiteboarding, the wb sub-node, contains who currently has the
> token (allowed to draw), the list of all the whiteboard elements by page
> number (lines, circles, images as IBB, text, etc...), wb size, current
> page, number of pages, etc...
> This explains why we are having problems with the PubSub spec:
> 1) we need to have a known consistent way of handling updates to nodes and
> items in a persistent PubSub tree (i.e. the whole 11.3 section discussion
> over the last couple of weeks). 2) we need a clear way of handling
> notification of changes to sub-nodes and items. I think collections will
> solve this. 3) a change to a publisher's rights to allow any publisher the
> ability to delete another publishers nodes/items.
> boyd

Semantic Gap Solutions

More information about the Standards mailing list