[Standards-JIG] New version of chess game protocol

Michal 'vorner' Vaner michal.vaner at kdemail.net
Wed Oct 18 20:57:47 UTC 2006

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.  
> >wrote:
> >>On Sep 14, 2006, at 11:04 AM, Michal vorner Vaner wrote:
> >>* I disagree with the use of the 'gid' and 'sid' attributes. There is
> >>already a tag for this purpose: <thread>. This will allow clients/
> >>servers to recognize that all messages in that game are related--even
> >>if it doesn't understand that it is a chess game. Support for the
> >><thread> tag should be mandatory.
> >
> >But there are 2 types of this. Maye the thread would be the same as  
> >sid,
> >but gid is between many people.
> Why would the <thread> stanza not be appropriate in all cases? I'm  
> not quite sure what the use case intention of the 'gid' attribute was  
> in the first place.

Well, I wanted to address both the session between two people and the
game as a whole. But it may be unneeded to have different id for the
whole game than for the 2 players, one game will not have 2 sessions
with the same opponent probably.

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

> I think that a client should always assume that the game is in-play  
> unless 1) the user explicitly ends a game, or 2) the client receives  
> a notification from the other client that the game is over.
> >>* 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).

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

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

The game protocol could be built on top of PEP, however, that would be
probably more complicated.


Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20061018/897aed2a/attachment.sig>

More information about the Standards mailing list