Question about Sjaak

[Michel]

I know how appealing that idea is (I use it for UCI2WB too), but for communicating with an ICS that might simply not be possible.

Well IMHO it works well enough... FICS is perfect (almost all the 24/7 bots use icsdrone there). ICC is as good as perfect. I could make ICC perfect too but I do not want to invest time in a commercial entity.

[hgm]

Yes, I suppose engines would not adjourn too often anyway.

But sending SAN to an engine that did not request it through feature san=1 will do far more harm than good.

[Michel]

Yes, I suppose engines would not adjourn too often anyway.

Yes and even if they to do chances are remote that there would be a 3-rep draw just at the point where the game is adjourned (contrary to what I said, a 50 move draw is not a problem since that information is part of the fen sent by setboard to the engine).

But sending SAN to an engine that did not request it through feature san=1 will do far more harm than good.

I really don't see what harm you are referring to. It is up to the user to allow this. If it works then fine. If it doesn't just disable it.

It is silly that in the winboard protocol engines have to choose between san=0 or san=1 even if they support both (like for example Polyglot does). I am not responsible for this.

[hgm]

You mean that icsdrone waits for an "Illegal move" response or an "Error (unknown command): Nf6", and sends the start position if it does encounter one anywhere during the loading of the game history? I would consider that still more risky than starting from the board and taking the 3-fold-rep chances. Many engines cannot reliably distinguish moves from commands, and some engines do not send proper error messages, or no error messages at all.

The san=1 feature is the worst aspect of CECP, but I am also stuck with it for reasons of backward compatibility. I guess the protocol specs don't say that it is upto the discretion of the GUI to decide if it will send SAN or coordinates, because the whole feature mechanism already makes it optional: if the GUI prefers to use coordinats it should simply reject the feature. So according to the specs san=1 is exactly what you want, telling the GUI that the engine supports both SAN and coordinate notation, so that engines that can understand SAN would send it. In practice engines do not account for rejection of features, however.

OTOH, it is hard to see why an engine that would have implemented SAN parsing would not send san=1. They certainly would not get SAN from any compliant GUI when they do not send it.