Hello,
I am planning the architecture of a multi-player game that will be
based on XMPP.
In the game, there is a concept of game rooms which will be
represented by MUC chat rooms. Each room will be joined by an arbiter
bot who will manage the game being held in that room. XMPP messages
exchanged in a room will be game commands never seen by the end-users,
so it will effectively be a conversation between the game clients and
the arbiter bot.
There will be an external component responsible for managing the game
rooms. It will monitor the number of players currently logged into the
XMPP server and create or delete game (MUC) rooms as needed.
On the game UI side, we have a "lobby" where players can see which
rooms are currently available, as well as the count of players in each
room and the state of the room (waiting for more players, game in
progress, etc). In the lobby, we want the UI to refresh in real-time
so that it always shows the current stats of each game room. If game
rooms are created, they should appear immediately in the lobby. As
other players join a room, the player count for that room should be
updated in the UI.
When the lobby is initially displayed, I can do a disco IQ to the MUC
service to retrieve the list of game rooms and their attributes, but
that info is static. If 2 more rooms appear 3 seconds after the
initial disco, they won't appear in the lobby. I could do polling by
issuing a disco IQ every few seconds, but that wouldn't quite fit in
the XMPP spirit, would it? :)
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.
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.
I just had a little chat with Peter Saint-Andre about this, and he
mentionned that there had recently been some discussion about defining
a "disco#meta" protocol to replace the use of service discovery
extensions (XEP-0128) for things like this. He said that this was
something that would/could be discussed at the XMPP summit next week.
At the end of the chat, it was agreed that I should describe my use
case on this mailing list to make sure that some public follow-up can
occur, so here I am...
If there ever is a concensus on how to this, I'll be glad to follow
the spec! However, I am also ready to implement my own mechanism if
needed. I'll be happy to share my solution with the community, however
it might not be spec-worthy as I am new to XMPP so I might not come up
with the most elegant solution...
For now, I'll wait until the summit is over to see where this is going
with the official spec. If there is some discussion about this topic
during the summit, please post a follow-up to this thread!
Thanks!
Pascal Bourque
Loopycube
[1] http://mail.jabber.org/pipermail/standards/2008-April/018612.html
