[jdev] A case for private XML storage in MUC rooms

[Steve Smith]

> >         
> >         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).

Cheers,
Steve