[Standards] New Proto-XEP: Multi-User Gaming
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.
-------------- next part --------------
A non-text attachment was scrubbed...
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