I guess there is an important distinction between protocol specs, and a guide for engine authors on how to implement WB protocol. In the latter case it would be acceptable, and perhaps even desirable to make a selection of the protocol, and only present the alternatives we recommend. If we want to simplify the presentation, there is a whole lot of commands that seem almost useless to anyone that only wants to make a regular engine, rather than (say) a bot that directly interacts with an ICS to give commands and chat with people there. Basically all commands I grouped under 'frills' fall in this category, plus the features to switch them on. So we could prescribe the use ofmichiguel wrote:I think commands like edit should not even be discussed in a new description. When there are two ways of doing things (edit v setboard, for instance) the one that is preferred should be described and the one that is obsolete should be given a link to an appendix (in this case, the appendix could be the old protocol description). Description of obsolete commands are distracting and should be discouraged.
feature ping=1 memory=1 smp=1 setboard=1 usermove=1 debug=1 draw=1 colors=0 sigint=0 sigterm=0 done=1
as fixed final response to 'protover', (which could be preceded by more feature commands), and remove discussion of these features (except done=0) from the description, as well as the 'edit', 'white', 'black' and 'playother' command, and the Linux signals. When we then also kick out the commands 'ics', 'name', 'rating', and their associated features, as well as all the ICS tell commands (tellall, tellother, tellopponent, tellics, tellicsnoalias) and feature san.
The 'variant', 'setup' and 'piece' commands, and 'feature variants', as well as the highlight protocol could be kept in a separate section which most people would not read, of which the Bughouse stuff could then be made a sub-section.
Some things I am not sure about how we should handle them:
* is there any point in restricting the set of commands that must be received in analyze mode? The old specs give a list, which already contains some commands that XBoard would never send in analyze mode (like 'new' and 'setboard'). In any case 'option' would have to be
added to the list, as it is desirable to be able to change the multi-PV setting during analysis. But personally I don't see any reason why commands like 'go' and 'force' should be forbidden. None of my engines that support analysis would have any problem with those. ('exit' seems to be a synonym for 'force' anyway...)
* should we encourage the use of the 'usermove' prefix, or rather discourage it? The prefix makes it easier to distinguish unknown commands from illegal moves (to give the proper error response, which is important). But it makes it very annoying to use the engine from the command line.
* I adopted the policy to always request sending 'memory' and 'cores' commands; engines that have no use for them can always ignore them, or respond to them with Error (unknown comand). There seems no reason to complicate things by switching off commands you have no use for. (In this respect it is inconsistent to send feature colors=0. I am not even sure why GUIs would ever want to send 'white' or 'black' commands when they do not use 'edit', but apparently XBoard does (at least for 'white'). Is this one of those silly work-arounds for badly non-compliant engines that people have long since stopped using, and now puts a burdon on all compliant engines to switch it off or suffer the silliness?