[Standards-JIG] New version of chess game protocol

Robert B Quattlebaum, Jr. darco at deepdarc.com
Mon Oct 23 21:22:55 UTC 2006

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:
>> On Oct 5, 2006, at 6:26 AM, Michal vorner Vaner wrote:
>>> On Wed, Oct 04, 2006 at 11:02:08AM -0700, Robert B Quattlebaum, Jr.
>>>> * I would not consider the receipt of an unavailable presence as an
>>>> automatic forfeit. What if I get temporarily disconnected?
>>> But what if you get really disconnected? Will the session stuck here
>>> forever?
>> The client should pause the game until the other resource is again
>> available. If a client sends a move in a message to another player
>> but that player's client doesn't know what game it is talking about,
>> perhaps an error stanza should be sent in return.
> Well, but what if it does not reconnect? Will the game stay paused
> forever?

Um.. well.. yeah.. until the user closed it manually. I think this is  
perfectly reasonable behavior, but it is up to the client  
implementation to decide I suppose.

>>>> * 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.

>> 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.

> 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.

> 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.

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

More information about the Standards mailing list