Author: Peter McKenzie
Date: 16:23:53 11/28/00
Go up one level in this thread
Firstly, thanks to Stefan for posting this stuff and making it public. If nothing else, it'll stir up some interesting debate about the winboard standard in particular. On November 28, 2000 at 13:33:06, Robert Hyatt wrote: >On November 28, 2000 at 09:15:30, Stefan Meyer-Kahlen wrote: > > > >There are a couple of _really_ ugly things in this. Ugly because they are >diametrically opposed to other GUIs like xboard/winboard/robofics/etc. > >1. The search vs ponder stuff. I don't see why the GUI has to tell the >engine to begin to ponder. This makes no sense to me, from either a GUI >point of view, or an engine point of view. But the main problem is it is >so different from xboard that the code is going to be very messy. And for >no gain that I can see. Yeah, I'm not too keen on the way pondering is handled. It doesn't seem very flexible for starters. > >2. sending too much control info to the engine. The engine ought to be able >to manage itself, sending moves to the GUI and reading moves from the GUI. >Having a protocol to alter other things like selectivity and so forth is fine, >as is having a protocol that allows the engine to tell the GUI certain things >like offer a draw or whatever. > >3. The main thing you have really addressed is "race conditions". One thing >the winboard/xboard protocol is sorely missing is some sort of ack/nak facility >(it has a sort of nak facility if you send an error message) to eliminate the >race conditions that occur. IE the interface says "start a new game" and >immediately assumes this has been done. If you don't check for input quickly >enough, you miss the new game indicator for a bit, and if you send a move, >that move can be sent to the server with an immediate "illegal move" response >since your move came from a game that has ended. > >I don't personally like to ack/nak every message, as that does nothing more >than ramp up traffic. But for critical events (ie new game) an ack would be >nice so that xboard would wait for you to say "ok" before it would proceed to >start a new game, etc. Right, I agree 100%. > >Before this goes too far, it would seem reasonable to design an interface >once and for all, that everybody will use. That means we need Tim Mann (or >someone familiar with xboard/winboard that is willing to make the needed >changes), someone familiar with ROBOFICS, so that we can have one common >protocol. Right now, what you are using is so different from the >xboard/winboard protocol, it will make some things very messy to keep >compatibility with both. I think Tim Mann has done an excellent job with xboard/winboard. He has carefully improved the protocol (and documentation of it) while keeping pretty good backward compatibility. As you imply, I'd prefer to see any 'once and for all standard' based as closely on winboard as possible - and Tim should definitely be involved. > >I don't like the idea of dictating what the engine can and can't do without >permission from the GUI. I think the engine should be free to do anything it >wants. Otherwise the GUI might assume the engine is idle and not using CPU >time and be wrong. Specifying the comm protocol is fine. Specifying a time >limit for responses to commands is fine. But don't specify what the engine can >and can't do while waiting for another command... ie why can't it "ponder" >all the time? Why does it have to keep searching after it has found the >shortest possible mate? etc... That last point might be important as it >wastes compute cycles. > > > <snip>
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.