-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralph Meijer and I talked a bit about this in a Council meeting and at the XMPP Summit but haven't had a chance to work on it. Is anyone else interested in helping?
On 7/16/09 2:36 PM, Pascal Bourque wrote: > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqxRb8ACgkQNL8k5A2w/vz4OwCgpjOxhwwc5EBFdNQL4Ep7YCsi XEcAoPRfWVfBNp8OJMKJ3f37VKjXPdae =gBW5 -----END PGP SIGNATURE-----
