Possible break of backward compatibility

[Rohan Padhye]

http://www.tim-mann.org/xboard/engine-intf.html#13 - Idioms and Backward Compatibility

That section is supposed to support backward compatbility, and I feel there might be one particular new component in version 2 that could break it - specifically the recognition of rsh fatal errors.

Reason: WinBoard is known to ignore commands it does not understand, this leaves programmers free to write human readable messages to the screen which are useful in interactive mode but are ignored by winboard. I've been using such output liberally... In particular, if at startup the book file is not found, I would print "Book file not found." and play openings via searching... However, Winboard reads the words 'not found' and pops up a fatal error and exits.

Now, for my engine this is fine because I can just rephrase. However, what if some old engines were using these phrases in normal output (maybe even 'command not found' or 'tried to increase hashtable but can't alloc more memory') possibly for debugging purposes...? Won't this break compatbility between WinBoard 1 and WinBoard 2?

[H.G.Muller]

Backward comptibility is not guaranteed for engines that violate protocol. Guaranteeing it would basically make it impossible to ever extend the protocol.

"WinBoard is known to ..." is a statement about behavior of some actual implementation. It is not a feature that is anchored in the protocol. In fact the protocol specs say:

9. Commands from the engine to xboard

In general, an engine should not send any output to xboard that is not described in this document. As the protocol is extended, newer versions of xboard may recognize additional strings as commands that were previously not assigned a meaning.

So it is a protocol violaton to send such output, and the effect of it is undefined. This might indeed mean that some engines, which used to run under old WinBoard versions, might fail to run properly under newer WinBoard versions. Such engines are to be considered broken. There is not much that can be done about it. Yace is one example of this. (I am not sure what the the protocol v1 description said about this; the quoted paragraph is in red in the v2 specs, suggesting that it is new, but it might replace a similar statement in the v1 specs. It is quite normal that every action not defined in a protocol has undefined effects.)

The protocol has been extended with a mechanism that allows engine programmers to send whatever they want without the possibility for any future implementation to be confused by it. This is by sending feature debug=1 at start-up, and then preceeding every line of debg output with a '#' character.

Note that it is still possible to run engines that confuse newer GUIs with protocol-violating output, by using the InBetween adapter to filter out such output. That should be enough; it is my policy not to adapt WinBoard to cater to non-compliant engines, as in the long run this is a self-defeating strategy, which only promotes chaos.

[Rohan Padhye]

I get your point. You are absolutely correct about the fact that if you consider engines printing anything at all, then the protocol would never be extended. However, even the paragraph that you quoted about not sending the engine any extra output, as well as the debug feature, were added in protocol version 2. No doubt that this gives way for a much better path for the protocol to extend, however my only fear was that older engines based on protocol version 1 would have never read that note you quoted or know about the debug feature.

The specs also mention (in the same section you quoted):

It should be harmless even if you are talking to a (version 1) user interface that does not understand the "feature" command, since such interfaces generally ignore commands from the engine that they do not understand.

I realise the use of the word generally does not have any solid implications, but it supports my point that the old specs did not forbid extranous output - in version 1 engines and GUIs alike would ignore unknown commands. To further this point, the engines that are included with the Winboard distribution on Tim Mann's page are GNUChess and Crafy - both of which print liberally before receiving the xboard command to switch to xboard mode (in fact GNUChess 5 even says "Adjusting hashtable to..." even after it knows that it is xboard mode).

The point I wanted to initially put across is that adding new commands in further version of the protocol are useful when extending the usability of the protocol (such as the addition of feature and setboard in version 2). The worst that can happen for an old engine that says "feature" by mistake is that xboard prints an error message which the engine ignores and life goes on. However, suddenly deciding that any phrase that contains the words "not found" or "can't alloc" should be treated as a FATAL ERROR, is, in my opinion, a little extreme. Then again, I don't even know what rsh is, so you would probably know better. This is just my comment.

[H.G.Muller]

rsh stands for 'remote shell', and is a way on linux to run commands on another machine. It can be used when you have XBoard running on one machine, to connect to to engines running on another.

For engines that send unknown features, or commands that are mistaken for feature commands, just cause the reponse rejected xxx, which is pretty harmless. (Except that one version of DanaSah once printed 'feature rejected' as an error message when one of its features was rejected, which of course then led WinBoard to print rejected rejected, which went on forever. )

I have never seen the specs of the v1 protocol, so I could not say what its recommendations were for bombarding the GUI with garbage. The remark you quote is just an observation about what existing implementations did at the time. It cannot be even understood as a recommendation that GUIs should behave that way. I guess that if any engines would have problms with protocol v2, we would know it by now. There is a WinBoard option to force protocol v1 to be used on an engine, but I think this only suppresses sending of the protover command. It does not affect understanding of the engine->GUI commands that are new in protocol v2.

We could adopt the requirement that the recgnition any new future engine->GUI command will have to be enabled with a feature first, making it even less likely that there are existing engines that send a matching feature and garbage mesage. For the rsh stuff this could not be done, as the error messages that are recognized are error messages the remote shell sends when it fails to start up the engine on the remote computer, and thus before any feature command could possibly be sent.

I did make WinBoard sensitive to setboard as an engine->GUI command, allowing the engine to break off the current game and set up a new one (which someone requested for teaching purposes). Perhaps it was unwise to do this without an enabling feature, especialy since this was an undocumented etenon of the protocol.

Anyway, new engines are supposed to conform to the current document, including the red and green stuff, even if they use the v1 protocol. The only difference is that v1 engines don't send feature commands, and thus are not able to alter GUI->engine behavior from the default (which is chosen to mimic v1). Older v1 engines are now legacy, and one can only hope that they still work. Or use (powerful) kludge tools like InBetween to run them.