bob wrote:
Here are some examples of what I mean by "cedes too much control to the GUI."
1. GUI can make opening book moves.
2. GUI can play endgame database moves without any input from the engine
These are not protocol properties as both protocols allow this mode of operation. These are things the user typically does on purpose, and typically wants to have control over. The user wins if it works the same for every engine. It lowers the acceptance threshold for that engine if it behaves the same as the others.
3. GUI tells engine when to ponder, when to search, what time limit to use, etc.
UCI drivers typically don't let you ponder unless it is out of book. That is a disadvantage of UCI. But that can also be solved in the driver/GUI without protocol change. In the meantime every engine suffers in the same way. (Mind that you are free to ignore the ponder move suggestion in the ponder message. The UCI spec makes that explicit.)
All other pondering is the same with both protocols, as far as I understand the specs. You get the ponder message immediately after you make your move. You don't have to program remembering the game's ponder mode (the 'hard/easy/force/white/black/go' mess inherited from the gnuchess cli mode), which is an advantage for the programmer. It is ironic that not even gnuchess has these anymore, but it lives on in programs that copied that design in order to interoperate with xboard. With UCI you can get rid of all of that.
4. Most chess engines want to receive a move, then generate a reply, until the game ends. They don't want to have the entire game's list of moves stuffed into them before each move. That seems beyond retarded.
This is a non-techical argument. Programs don't "want" things.
The UCI way has advantages here to the programmer because he doesn't have to implement additional commands for analysis, takeback, white/black/force, game resumption etc. The user doesn't care if the message is a couple of bytes longer. There is no real performance impact. Even if following the move list is too much, cycle-junkie-wise, you can always program to skip the moves that were unchanged since last move. That takes one or two lines of code. But why bother, the move notation is designed to be fast to parse.
And it would be a disruption. Such a big disruption that years ago I had to write special code to prevent ChessBase GUI from breaking Crafty's pondering savings by doing this same stupid nonsense. I don't want to do it again.
The problem you mention is one of a bogus driver/adapter that sent a 'newgame' command before every move in a game. That is not typical behaviour for native drivers. Does SF makes the same workarounds you mention?
In short, for me, xboard works perfectly.
The key perspective is 'me'. By releasing it, people get the impression that it is intended to be used by chess players. For Crafty that may not really the case, and its releases primarily intended to be looked at by other programmers. One can also see UCI support as an opportunity to increase the potential user base, because it works with all interfaces while the gnuchess protocol doesn't, or gives practical inconveniences for users, and users ask for it. There are disadvantages from the programmer's point of view, but the users apparently don't share the same perspective on those. The UCI protocol didn't become the primary engine standard for no reason.
