Werner Taelemans wrote:
But you can start from scratch! There is no reason why protover 3 should be compatible with the past. Would it be so bad, to change hard/easy into ponder true/false, for example?
Yes! Absolutely! It should clearly be "ponder on" and "ponder off".
There is an issue with backward compatibility to consider, and knowing whether an engine would depend on legacy "hard/easy" commands. One could also argue that "ponder on/off" should be treated as an option ("option ponder=1") instead, and similar arguments could be made for "cores" and "memory", or even time-control settings...
Evert wrote:[...]One could also argue that "ponder on/off" should be treated as an option ("option ponder=1") instead, and similar arguments could be made for "cores" and "memory", or even time-control settings...
In fact having a set of commands or a list of options is almost the same. having both in the same protocol could result in appearing a bad designed protocol; sometimes you set an option, sometimes you call a command and you really don't know why one or the other solution has been choose.
Werner Taelemans wrote:But you can start from scratch! There is no reason why protover 3 should be compatible with the past. Would it be so bad, to change hard/easy into ponder true/false, for example?
But what exactly would be gained by rewording the same commands?
As to commands and options, in CECP they emphasize the difference between standard features that every engine should know about and use in the same way, and engine-specific features that the GUI is not exected to know about, and thus has to get the specific (like option type, range and default value) that for standard features would be redundant.
But seriously, I don't think renaming commands is going to do anything for the appreciation of a protocol. UCI also has silly keywords, like 'readyok'. Basically the golden rule on protocols are
1) Never make a new protocol
2) Never change anything that already works
Any change always leads to severe problems with backward compatibility, where bot the GUI and engines will have to support old as well as new method to guarantee their interoperatability, so it should never be done for frivolous reasons.
I agree there are some strange aspects to the design of WB protocol v2. Like the possibility to switch off the GUI use of some commands for which there is no alternative, or which were meaningless in the first place. Where the logical solution would have been to let the engine simply ignore these commands, or let them evoke the "Error: unkown command" response like any other garbage the engine would receive. The feature colors=0 seems useless, as the white and black commands are redundant for engines that support setboard, where side-to-move info is encoded in the FEN. So a GUI should not need any encouragement to refrain from sending them to such engines. They are just part of the 'edit' method for setting up positions (and even there they can be avoided through a kludge, by preceding the edit with new or new + force + usermove. As for suppressing sending of time commands by sending feature time=0, this is just an organized way of breaking correct operation, as there is no alternative to the time command for syncing the engine clock. And the conclusion that the engine does not support the time command could have been drawn by the GUI easily enough when it received an 'unknown command' response to it.
The desirability of feature setboard=1 is already very doubtful. It is true that the original edit command was broken, through not being able to convey castling and e.p. rights, but this could have been easily be repaired in a backward-compatible way (as ChessBase indeed did).
hgm wrote:
As to commands and options, in CECP they emphasize the difference between standard features that every engine should know about and use in the same way, and engine-specific features that the GUI is not exected to know about, and thus has to get the specific (like option type, range and default value) that for standard features would be redundant.
You know what? That makes sense, and I think it's aesthetically better than adding a prefix to standard options.
Werner Taelemans wrote:But you can start from scratch! There is no reason why protover 3 should be compatible with the past. Would it be so bad, to change hard/easy into ponder true/false, for example?
But what exactly would be gained by rewording the same commands?
In practical terms of engine/GUI communication? Nothing, of course.
But there is the advantage of making the protocol more easily accessible to humans and it looks cleaner, for what that's worth. For a computer there is no real difference between matching strings "new", "time", "level", "hard" or "ponder on" or matching strings "fibble", "faz", "wazlib" or "qubixtotl" but the latter would make a rather poor protocol.
The question is: does the benefit of such a change outweigh the cost (you'd need a way to handle the incompatibility, although you could send "ponder on" by default and switch to "hard" if the engine responds with "unknown command: ponder on")?
Possibly not.
Evert wrote:[...]The question is: does the benefit of such a change outweigh the cost (you'd need a way to handle the incompatibility, although you could send "ponder on" by default and switch to "hard" if the engine responds with "unknown command: ponder on")?
Possibly not.
The debate about UCI/xBoard protocol seems to have interested a lot of people and the thread gets longer... so the real question is: "is it the right time for a new protocol?".
Of course i mean a protocol that gets the best from the actual two major ones and that consider the modern aspect of modern chess engines and hardware.
I already know some of the answers to this question...
I guess one of the problems is that you cannot 100% rely on existing engines properly implementing the 'Error: unknown command' response, and what you propose would break those (basically non-compliant) engines. The point is, "should we care?". The approach with XBoard development has always been extremely forgiving and cautious in this respect, to make sure that everything that happened to work before, no matter how flakey and non-compliant, would continue to work.
This reminds me of the stage I am in with USI engines. Many of those have a very original interpretation of the protocol directive that they should ignore any command or keyword that is not suppose to come at that point: they segfault immediately.
Requiring an engine to send a command disabling sending them commands on which they would crash, is madness though. If anything new would have to be implemented in such engines, it would be properly responding to the command on which they crash. (Even if only by emitting the proper error response.)
