[Standards] New Proto-XEP: Multi-User Gaming

Peter Saint-Andre stpeter at stpeter.im
Tue Jul 29 18:14:08 CDT 2008


Arne König wrote:
> Hi Jack,
> 
> Jack Moffitt wrote:
>> It is quite easy to extend MUC.  One way is through plugins in your
>> muc implementation.  For example, Chesspark creates a new role in our
>> game MUCs called "player".  Players don't normally receive messages to
>> the room from non-players.  This is so that people watching the game
>> cannot interrupt them or help them accidentally.  However, player chat
>> is seen by everyone.
> 
> There are two different thing to look to at here. First is the protocol
> level. Extending the MUC protocol is fine. But changing the routing
> actually breaks MUC since routing in MUC isn't intended to be changed.

I think it's OK to change the routing, e.g. with a special extension in 
the message. So if the MUC room receives a message of type groupchat 
without the message, it reflects the message to all occupants. But if 
the message has a special extension (e.g., specifying a certain team) 
then the message is reflected in a special way (not broadcasted to all 
recipients). This could also be done (more easily perhaps) via bots, 
such as foo at games.example.com/red for the "Red Team" and 
foo at games.example.com/blue for the "Blue Team" or whatever.

> The second problem is the implementation. Adding a role to the chat
> requires changes in both server and client MUC implementations. In many
> implementation that is hard to accomplish. We try do create a protocol
> that can be implemented in most clients and servers. If you take
> Openfire for example. Their MUC component doesn't have a plugin
> infrastructure. Thus to change the routing of MUC you would have to
> rewrite the whole component. On the client-side you have multi-protocol
> clients with similar problems.

It sounds like you need to use better implementations on the server 
side. :) But I agree that you'd like to use stock clients, so you need 
to minimize the diff for the client-to-service protocol.

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080729/fb86b24d/attachment-0001.bin 


More information about the Standards mailing list