> > > > 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 _______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev
