[Standards-JIG] New version of chess game protocol

Richard Dobson richard at dobson-i.net
Tue Oct 24 09:02:40 UTC 2006


> Ok, that sounds perfectly reasonable, but I would say that makes two 
> classes of games: those which need a 'referee' (something to keep 
> track of the game state independent of the players) and those which 
> don't. Chess and checkers do not need referees, and thus I think 
> requiring those games to use a game server for no other reason than to 
> have them under the same roof is a serious flaw, IMHO.
Sure that's fine I wasn't trying to say otherwise, my main point was 
that some games require a third party arbiter to even function (I wasn't 
saying all do), so we need to ensure that we keep this in mind and make 
sure whatever we design takes this into account and will work for both.
>>
>> I also refer you to 2.2 (Keep clients simple), using MUC as is 
>> requires clients to implement the validity checking rather than just 
>> using a server component that can do it.
> Again, I refer you to sections 2.3 (Re-Use Existing Protocols) and 2.7 
> (Stay Flexible) of XEP-0134 
> <http://www.xmpp.org/extensions/xep-0134.html>, Protocol Design 
> Guidelines.
I'm not sure exactly what you are trying to point out here, if you mean 
reusing MUC then that's fine, I wasn't saying otherwise, I was just 
saying that we also need something extra as well, have a look at Jack's 
description of how it works, he is more clearly describing exactly how 
what I have been trying to suggest would work.
> I'm pretty sure that this is in reference to protocol complexity. For 
> example, the SIP protocol requires very complex client implementations 
> simply to be able to communicate, whereas jabber puts most of the 
> complexity server-side. And this is a good thing.
No its not entirely in reference to protocol complexity alone, it is 
also in reference to the moving stuff out of clients where you can into 
the server where it will reduce the amount of complexity the client 
needs to implement and moves that into the server to deal with.
>
> What I am suggesting would actually simplify the chess/checkers 
> protocol, and remove the dependence on some new server-side 
> component--thus making it easier to use and adopt *right now*. Look 
> what happened to pub-sub. Relying on new server implementations is 
> dangerous for a protocol, and should be avoided if at all possible, 
> and it is quite avoidable in this case. I see no reason to force chess 
> and checkers (and other similar games) to use a game server when it is 
> quite simply not necessary.
That's fine, you have misunderstood me if you thought I was suggesting 
requiring all games to user a server component, just trying to point out 
some will not work without one, but I would dispute your assertion that 
implementing the checking in the client simplifies things entirely, if 
you do just use a game server it means the client does not need to do 
any validity checking itself, and can just rely on the moves the game 
server sends it, i.e. being a dumb client of the game which means you 
are more in the spirit of point 2.2 of the design guidelines.
> Unless you want to abandon the ability for two people to conduct a 
> private chess/checkers game between themselves (which would be a 
> horrible idea, IMHO), it seems that the clients MUST implement some 
> sort of validity checking anyway. So my suggestion would not increase 
> client complexity, only decrease dependency on fancy new server 
> components.
That's exactly what your suggestion does, i.e. reduces dependency on 
server components at the expense of client complexity, now i am not 
saying this is a bad thing, personally I think its fine to allow clients 
to have more implementation complexity and support server-less direct 
games if they want to, but I also think that for the ones that want a 
more simple implementation and require a game server to handle all the 
validation of moves etc (like in Jack's clearer example) we should 
support that too.

Richard





More information about the Standards mailing list