The reason for adding the restrictions was that (at that time anyway), we had engine authors who were unhappy about having to support all commands in all modes, and who found the protocol spec unclear about what some of the commands would mean when not in force mode or if issued while the engine was thinking or pondering. In some cases it wasn't clear even to me what those commands should do in other modes.
OK, I ould have to look what exactly the problem areas would be, and perhaps just specifying what they should do would be a better solution.
The restrictions were meant to clarify things that xboard already does (or rather, that it already doesn't do), so adding them shouldn't break the interaction between xboard and any engines. However, in theory it could break other GUIs that use the protocol if they happen to send those commands when not in force mode.
OK. I was a bit worried about the specs that "force" should not be sent "if the engine is not thinking, pondering or analyzing", which pretty much would mean you can never sent it after you switched pondering on... But I see that this phrase was only contained in the attached version of the draft, not in the two versions from the exchange between Daniel and Martin that you pasted into the e-mail. So I guess these were of later date, and that this condition had already been dropped. The spec that "quit" should only be sent when the engine is in force mode also seems a bit like overdoing it: could there ever be any doubt as to what "quit" means in any mode? I wil have a closer look to the matter in view of what you told me.
Still, I'm not strongly in favor of adding the restrictions, and I haven't looked at them for a long time and am not certain that all of them are reasonable. -- Tim Mann [email protected] http://tim-mann.org/
