Re: [XBoard-devel] Protocol development (old v3 draft)

[h.g. muller]

> 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  address@hidden  http://tim-mann.org/