[Standards-JIG] New version of chess game protocol

Michal vorner Vaner michal.vaner at kdemail.net
Thu Oct 5 13:15:18 UTC 2006

On Tue, Oct 03, 2006 at 04:36:44AM +0530, Mridul wrote:
> Michal vorner Vaner wrote:
> >Hello,
> >there is a new version of the chess game protocol in the inbox.
> >
> >http://www.jabber.org/jeps/inbox/chess.html
> >
> >If you want to have a look, I would be delighted to hear opinions.
> >
> >Thank you
> >
> >  
> Hi,
>  Some thoughts on this proto-jep , and also on gamesessions (in the 
> context of this proposal).
> gamesessions :
> 1) Who creates the gid ?
> If it is the responsibility of the client , then how can it be expected 
> to be unique ?
> From my understanding , gid will identify a game to which others could 
> potentially connect - so shouldn't this not be assigned by the server ?

It is created by the one who first needs to put one there.

Well, it is created by the client. But as mentioned in the JEP (I hope I
did mention it somewhere), it SHOULD contain full JID of the creator and
a timestamp or some kind of hash of this, so it will not happen someone
just asks you again with the same ID. The client could then mismatch
the 2 games.

> 2) "One to one game, with spectators" - In the context of chess games , 
> which is essentially falling under this category :
> Are the client's supposed to take care of it ? 

Under "normal" match, you usually do not want people to watch, so you do
not need it. And even if you want some friend of you to watch, you have
this mirroring better (it seems to me) than negotiating for a server
component, which actually does not exist, you have to discover it, which
is error-prone (see actual state of file transfer proxies).

> Or do the spectators 
> connect to the component/server and view a game ?
> It would be heavy if the client has to manage spectating - imagine 
> kasparov vs anand game :-)

Hm, it would need some kind of "man-in-the-middle" component. Maybe I
should not it there. It goes to TODO.

> Also , how about acl's for this ? (tutor session/class similar to muc , etc)
> Actually , I did not see anything about how a client would initiate a 
> spectating session for a game in the proposal.

There is whole section 8 about creating spectator session.

> Typically , spectating involves side chatter : some of which is also 
> visible to the players , and some of which are not : makes all the more 
> sense to move it out of the control of the client.

But where?
> chess :
> 1) Time related attributes.
> There are a whole series of timing considerations in chess games : sec 
> per move , fischer time control , primary/secondary/etc time controls of 
> time per x moves , etc : and different UI's support different subsets of 
> these.

Hm, I must admit I'm not really good in time and chess. I play chess
sometimes and I wanted jabber-based client, so I started writing one.
And when describing the protocol, I added some time measuring. Maybe I
will look at that.

> 2) There are variations of chess where more than 2 players play - this 
> is not handled by the spec I believe (refer to 3).
> 3) There are a large number of variants of chess - refer here for a 
> small list : http://www.chessclub.com/helpcenter/tips/wild.html
> There should be some way to negotiate this.

Well, these is not chess as is, you just can expect normal clients to
support this. So if you create special client for lets say 3-people
chess, you need to define new protocol, which may reuse this one as the
core and extend it.

> 4) Considering that you already have (3) above , I think the ruleset 
> attribute could be modified for this - the current rules mentioned are 
> not really very useful imo ...
> 5) There is a standard way to represent chess positions : FEN 
> (http://en.wikipedia.org/wiki/Forsyth-Edwards_Notation) for normal chess 
> , X-FEN(http://en.wikipedia.org/wiki/X-FEN) and shredder FEN for fischer 
> random chess - not sure about other variants.
> Similarly , for communicating games , there is a PGN standard format.
> It would make sense not to invent another format - all UI's I know 
> support FEN already.
> Btw , the 'piece' attribute could be considered broken from a chess 
> point of view actually.

Will have a look there.

> 6) Maybe I did not get this point ... but who manages a game ?
> The gamesessions seems to indicate that 1 to 1 games would be managed by 
> the players themselves ... in which case , time synchronization , 
> checking of rules , etc have to be managed by the client ?
> If not , then how are the errors , timeouts , etc to be sent ?

It is done by the clients. If one client "catches" the other while
cheating (or playing over time), it accuses the other one of it and

> 7) Might be useful to add a move number to gameflow. Also , it does not 
> consider extra semantics necessary for (3) above ...

Can't you just count in your client? No-one sends how many messages did
you sent already with chat, do you?

> 8) I am not very sure of the client's managing spectating ... might make 
> more sense for the server or external component to manage this (I 
> mention this under gamesessions actually).

Yes, I will try to think about the game component, which might be as
well used for the middle spectator. But I want simple (1 to 1) games to
be possible to play without any server support.

> 9) Other ideas which are currently available in most online chess server :
> a) Adjournment of game ?
> b) Retrieving a move list to continue a previously adjourned game
> c) Browsing game history.

No need for protocol for this one, if you need a chat history you keep
it. If you need game history, you keep it.

> d) Examine a game (could have multiple users modifying the board).
Well, I would not like to overcomplicate it, I want to be able to make a
simple client that allows 'only' to play chess.
> If I am not wrong , the protocol's of most of the online chess servers 
> are public (a search showed me icc format : 
> ftp://ftp.chessclub.com/pub/icc/formats/formats.txt , I am sure fics , 
> others will also have their formats out there somewhere)... so it would 
> help us to take a look at what they support and what they allow.
> We may not want to model all of it , but should be reasonably flexible 
> to allow the jep to be used for supporting these as required.
> Wanted to comment only about the time thingy ... but became a much 
> bigger mail than I expected :-)
> Regards,
> Mridul

Anyone who goes to a psychiatrist ought to have his head examined.
		-- Samuel Goldwyn

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/20061005/bf6d5a24/attachment.sig>

More information about the Standards mailing list