[jdev] A case for private XML storage in MUC rooms
ssmith at vislab.usyd.edu.au
Wed Jul 13 21:34:29 CDT 2005
> > 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.
> Well-known node locations are possible and disco items is there for
> discovering it too.
Is there a JEP on this? My understanding is that node-paths are opaque
and need to be publicised via other methods.
> For the access restrictions, a particular
> implementation of muc could publish the node automatically and
> updating access restrictions every time a user is registered or
> unregistered (or join/leave the room). Being on the same host and if
> the whitelist of subscribers is not persistent, there should be not
> much of an overhead for this updating.
It still requires active synchronisation of two sets of data (MUC
members and the pubsub access-list). So you need a bot or a MUC
implementation that contains a pubsub client implementation. And you
still need some method of publishing the node location (although
disco-extensions would be acceptable in this case).
If you're looking for a method of creating interactive applications I've
been thinking about methods of doing this, but I don't this is it (I've
also made some comments about this on the standards-jig list).
More information about the JDev