Hi,
On 2009/07/16, at 21:36, Pascal Bourque wrote:
So in other words, I need to monitor the state of the MUC rooms
(number of rooms as well as each room's attributes) in a PubSub-like
manner.
My initial plan was to implement a PubSub node hierarchy where I
would have one root PubSub collection node "game-rooms", and one sub-
node for each room. Then, as the room manager component creates/
deletes rooms, it would add/remove corresponding PubSub nodes from
the collection.
The room manager component would also publish notifications when
players join/leave a room. It would itself be notified by each
arbiter bot from each room, who get presence notifications when
people join/leave the MUC room.
I think this is sane, and it would allow you to reuse good PubSub
implementations out there.
But before proceeding, I wanted to make sure that this concept of
MUC notifications via PubSub wasn't already in the XMPP spec or in a
XEP somewhere, so I did a bit of googling. This lead me to this
thread from April 2008 [1], where it was decided to "remove the
disco-publish feature from XEP-0030 and implement it via PubSub".
So it seems like my requirement (ability for users to be notified of
MUC changes after the initial disco) was once adressed by XEP-0030
but not anymore.
No. I would need to check the previous versions but I *almost* certain
that XEP-0030 disco-publish feature was created to help clients deal
with the initial storm of disco#info requests. Basically, a client
would publish his disco#info information to the server, and from then
on, any requests for that information from other clients would be
replied by the server, and not the client.
Like a HTTP proxy cache, with the twist that the HTTP server would
push the latest version of the document to the proxy.
Others might know the true reason for that part of the spec, I can
only speculate. Maybe it was written to solve the initial thundering
herd of disco#info requests from everybody on your roster when you log
in. Right now, I think the latest XEP-0115 (after we solve the pre-
image attacks) is a better solution.
In anyway, for your use case, these are not the droids you are looking
for.
I would stick with pubsub: a lot of people are working on it, so you
will probably find more good quality code for the server-side
components.
Best regards,
