[jdev] A case for private XML storage in MUC rooms
Steve Smith
ssmith at vislab.usyd.edu.au
Tue Jul 12 23:51:31 CDT 2005
Hi,
I'm currently looking at methods of associating multicast addresses and
other metadata with MUC rooms, and I've come to the conclusion that
there is a case for per-room private XML storage, similar to
JEP-0049 ...
How it would work:
The semantics would be virtually identical to the JEP-0049 with the
following exceptions:
jabber:iq:private stanzas would be sent to the bare JID for the
MUC room rather than the server
Room members with a role of 'participant' or higher are able to
retrieve stored XML.
Only the room owner may add, update or delete stored XML.
(Question: should moderators have this too?)
Stored XML should only be persisted if the room is persisted.
Optionally, updates to stored XML could be broadcast to the
room, essentially creating a simple per-room pubsub
implementation.
Why:
I wish to attach persistent meta-data to a room in a manner such that it
is only retrievable by room-participants. There are other possible
methods of achieving this, but I believe this to have the best
trade-off, so I'll address the alternatives:
Use service-discovery extensions: This does not provide any
restriction on who can retrieve the information. Additionally
it would create a large overhead, as all data would be returned
in disco queries.
Add a query namespace for each piece of data: This requires
implementation of each namespace on the server for what is
intended to be opaque data.
Use pubsub: A method of specifying the location of the pubsub
node would still be required, and then additional
access-restrictions would need to be implemented on the pubsub
node itself. In particular the access-restrictions would need
to be updated to match the changing membership of the room.
More: There are certainly other angles I haven't considered,
comments are more than welcome.
Other uses:
There are plenty of cases where a room owner (and moderator?) may wish
to attach useful information to a room in a manner that doesn't require
them to be connected to the room: a longer MOTD than is suitable for a
subject line, room specific bookmarks (using JEP-0048), etc.
I'm going to create an implementation of this in ejabberd if anyone is
interested in playing with it.
Cheers,
Steve
More information about the JDev
mailing list