[Standards-JIG] New version of chess game protocol

Richard Dobson richard at dobson-i.net
Wed Oct 18 23:19:38 UTC 2006

>> Sure, and thats fine for some games like chess and checkers, but as 
>> detailed above, not all.
> Do you think it could be done with EMUC (as I mentioned in other
> thread)? The MUC behaviour could be modified and the logic could be
> inserted into it somehow more directly.

It could be yes, just like we could modify MUC to remotely control a 
coke machine if we wanted to build the extensions ontop of it to do so, 
the question is whether we should, IMO the sort of games im talking 
about that need the game server component need to do things that are 
different enough to warrant them being in a separate component (i.e. I 
think not sharing the full game state with all the players, i.e. 
broadcasting it via the MUC room, is different enough that its outside 
the intended purpose for it, IMO MUC should only be used for protocols 
where everything that is going to the room is sent to all players i.e. 
broadcast, not protocols that need to send different states to each 
player), like like how workgroups work.

> If you have MUC and something other that "knows" the game, you need the
> clients to assemble these two together somehow.

So..., the workgroups XEP works in pretty much the exact same way as im 
suggesting we do games, i.e. have a component that you do stuff with to 
start with that can create chat rooms on a MUC component as part of how 
it operates, its not difficult and its definately possible as the jive 
spark fastpath seems to work fine using the workgroups protocol.


More information about the Standards mailing list