[Standards-JIG] New version of chess game protocol

Robert B Quattlebaum, Jr. darco at deepdarc.com
Wed Oct 25 00:45:02 UTC 2006

On Oct 24, 2006, at 1:33 AM, Michal 'vorner' Vaner wrote:

> On Mon, Oct 23, 2006 at 02:22:55PM -0700, Robert B Quattlebaum, Jr.  
> wrote:
>> On Oct 18, 2006, at 1:57 PM, Michal 'vorner' Vaner wrote:
>>> On Wed, Oct 18, 2006 at 12:30:29PM -0700, Robert B Quattlebaum, Jr.
>>> wrote:
>>>>>> * For cases where there are spectators, why not use a MUC  
>>>>>> room? We
>>>>>> should try to take advantage of such facilities as much as
>>>>>> possible.
>>>>>> It will make client implementation of this protocol more simple,
>>>>>> and
>>>>>> thus more people will implement it. It is also more scalable for
>>>>>> games with large numbers of spectators.
>>>>> Hm, maybe because MUC does not support some things (iqs) and  
>>>>> alters
>>>>> it.
>>>> I'm not sure what you mean by "alters it".
>>> I guess no-one said it may not modify the stanza it is routing. For
>>> example, many of them modify the <presence/> stanzas. It may  
>>> strip of
>>> anything except <text/> part of the <message/> stanza. Or, it is  
>>> how I
>>> read the specs. (it does not say it is allowed either).
>> Yes, a given implementation can do this, such as for an IRC gateway.
>> But why the hell would you try to conduct a chess game over an IRC
>> gateway anyway?
>> In my experience, true jabber MUC implementations only add
>> information to the stanza, and don't generally strip. Even if there
>> were some implementations which did, I still think that it would be a
>> perfectly acceptable choice.
> So, if they can do it, we can not expect them not to do so. At last  
> some
> other feature to the usual implementation could be added (like
> http://jabber.org/protocol/muc#no-strip to the disco), so clients  
> can find the
> muc all by themselfs.

I don't think that it would be a bad idea to add such a thing.  
However, I'm pretty sure that there is nothing that says that an XMPP  
server itself can't mangle the packets either. (now watch someone  
prove me wrong)

However, I would say that missing this disco feature should not  
preclude a client from using the MUC for chess, only that MUCs which  
have this feature would be prioritized higher in auto-discovery.

>>>> MUC does not seem to explicitly define the forwarding of IQs  
>>>> (perhaps
>>>> it should specify it as an optional part of the spec), but it seems
>>>> that some implementations do this anyway(I noticed icons working in
>>>> anonymous MUC rooms with pandion). Either way, I don't think  
>>>> that the
>>>> forwarding of <iq> stanzas is a absolute requirement for this
>>>> protocol.
>>> No, not this protocol exactly. But there may be a game in the future
>>> that would need them.
>> I do not think that we should be creating this bloat of a protocol to
>> try to encompass every game we can think of.
>> I'm really thinking that we should have two types of games: ones that
>> need 'referees' (ie: a game server for maintaining the private game
>> state), and those which don't. Trying to have one protocol is
>> sounding less and less desirable.
>> The pieces are already in place to have both private and public chess
>> games in XMPP architecture. We need to make sure that we leverage  
>> that.
> OK, which would return the chess game back to the beginning without  
> game
> sessions and add a possibility to multicast the moves over MUC?
> So, if I get you right, you say there is no need for game sessions but
> for some kind of way to multicast over MUC XEP (still, what to do with
> <iq/>s and so, if they are forbidden to use, allowed, and how).

No, You would still use the <thread> element to describe the game  
session that moves are referring to, and you would still have some  
sort of handshake to start the game. Theoretically, you could have  
more than one chess game in a MUC, but that might be a little confusing.

>>> And no, it is not a show stopper. But I do not like the way it would
>>> work. It is one big workaround that could bring many problems in the
>>> future.
>> This is NOT a workaround. This is perfectly appropriate use of a pre-
>> existing protocol.
> Well, using multicast component for multicasting seems more natural  
> and
> right to me than using MUC.
> And as I said, the MUC would be OK for chess, but if we want all the
> games to behave more or less in the same way, then MUC will make  
> lots of
> problems in some games. (As I said, you know number of  
> participants, for
> the first thing, you need to keep ordinary clients out of the MUC
> somehow, which makes it harder to connect for game clients..)

There is no reason to keep ordinary clients outside of the MUC that a  
chess game is taking place in. Why would you want to do this, anyway?

>>> The game protocol could be built on top of PEP, however, that  
>>> would be
>>> probably more complicated.
>> I think that would be a bad idea, especially since MUC is a perfectly
>> good solution.
> So, lets suppose MUC is the solution for a moment. You get visitors  
> for
> free, you have admin, you have multicasting of <message/> stanzas and
> you have chat between the people. How do you propose to sort out these
> problems: (present in the easy chess thing)
> *) Allowing in only chess clients. Password is not nice way, since you
> need to let everyone know, so you can not just create the room and  
> wait,
> is someone connects.

This isn't a problem--there is nothing wrong with letting non-chess  
clients into the room. This is especially true if we use the <body>  
tag of messages containing chess moves to describe the move that took  
place. Then someone without a chess client could observe the game  
taking place.

> *) Choose the right MUC component automatically. I know you would  
> never
> try to play chess over IRC gateway, but what if there is a user, who
> does not see the difference? The client should choose it automatically
> if possible. How does the client recognize the MUC is suitable?

It should choose the a MUC component from service discovery that has  
the best looking disco results and that is not marked as IRC. It will  
be immediately obvious to the client when it attempts a game in a  
room if it is going to work or not (based on the echo from the room).  
If this happens, the client should choose a different MUC, or should  
give the user the option to choose from a pre-established list of  
good MUC servers. Perhaps we should suggest the additional disco  
feature you mentioned?

> *) If you wanted a game with referee, how would you do it? You  
> would add
> referee to the room and he would just kick anyone who made an illegal
> move? Or retract the moves somehow? Or you would need to specify
> completely different protocol for the game with referee?

You could have the referee be a bot that would complain when a move  
was illegal. Kicking isn't a horrible idea, but perhaps it is a  

Robert Quattlebaum
Jabber: darco at deepdarc.com
eMail:  darco at deepdarc.com
www:    http://www.deepdarc.com/

More information about the Standards mailing list