Author: milix
Date: 06:55:57 11/07/04
Go up one level in this thread
On November 07, 2004 at 03:14:29, Russell Reagan wrote: >On November 06, 2004 at 18:58:04, Pallav Nawani wrote: > >>Hi, >> >>Personally, I don't want to support any 'special features' in GUIs. This will >>lead to WB protocol becoming confusing, as now every GUI has its own features >>not available in the other. ChessBase8 may have a feature, chessbase9 may have >>another, new, feature. So now the GUi string >>gui chessbase >>Dosen't cut it anymore. YOu need >>gui chessbase8 >>gui chessbase9 >>etc. >> >>In other words, authors whose programs use WB2 protocol will have the task of >>maintaining a small DB of GUI's within their programs. Even worse, different >>GUIs will decide to use different names/strings for a same feature. This will >>become messy. If some GUI has a useful new feature, it is probably better to add >>it to the Winboard protocol proper, rather than leave it at the mercy of GUIs. >> >>Note that I don't have any objection to the gui command, I just feel that using >>it as a basis to have special code for separate GUIs is not something I want to >>do. >> >>Regards, >>Pallav > >I want to see some improvements to the Winboard protocol, but I have to agree >with you and I don't think this proposed change will result in an improvement of >the situation. The only significant measuring stick for the Winboard protocol is >the UCI protocol, which is more attractive IMO (as an engine programmer and >especially as an engine user). Compared to UCI, Winboard is already a bit >clunky. I think the existence of the 'feature' command is enough. > >Unless there are improvements to the Winboard-2 protocol, I think the Winboard >protocol is on the way out and UCI will continue to grow in popularity. I fear >that adding more complexity to support every GUI extension under the sun would >only accelerate Winboard's departure. Anyone writing a new engine will look at >the two protocols and see a nice, simple, user friendly protocol in UCI with a >relatively small downside, and something complicated in Winboard (relative to >UCI). A new computer chess programmer won't care too much about the common >drawbacks of UCI. > >I don't like that my engine can't resign, accept draws, offer draws, >kibitz/whisper to an ICS, and that I have to "trick" the protocol to ponder the >way I want to using UCI, but the pros outweigh the cons IMO, and there are >tolerable workarounds. > >I'd like something in the middle, ideally. The Winboard protocol has contributed >very significantly to the popularity of computer chess. UCI improved upon the >Winboard protocol in some areas. I'm waiting for something that improves on them >both. Creating my own protocol and GUI is something I've been working on for a >long time (on paper), but it is definitely a non-trivial task. I've also >considered the idea of writing an adapter that understands both protocols >simultaneously, or maybe a UCI-to-WB adapter that allows some Winboard commands >(ex. for kibitzing analysis in a CCT event, etc.). Hi Russel Personaly, I believe the above was true for WB 1 but it is not for WB 2. The feature command, the setboard command and others added the needed flexibility to the x-board protocol. Besides the protocol it is not that complex. On the other hand, the UCI 1 protocol has the serious drawback of not knowing when a new game is started. It is clear to me that WB suits nice for engines that play chess games and UCI is for engines that are used for analyzing positions. When analyzing you not need to know if this position is a new game or not. it dosn't matter. You also need to see many alternative lines, thus and the multivariation support in UCI 2. My bests, Anastasios Milikas
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.