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 [EMAIL PROTECTED]/red for the "Red Team" and [EMAIL PROTECTED]/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
smime.p7s
Description: S/MIME Cryptographic Signature
