Don Dailey drd@supertech.lcs.mit.edu writes:
However, I'm not sure whether error messages need to be standardized.
I agree 100% with this.
By the way, "not_implemented" is not an error message, it's a legitimate response that does NOT indicated an error. It's a way of saying, "I have not implemented that command."
There has been a tremendous amount of resistance to adding even very simple commands, the main argument being that it's extra work to implement more than the very most basic 4 or 5 commands. Having a set of standardized error codes for each command is certainly not very compatible with this philosophy.
It may not just be that it seems to be too much work. Another problem is that requiring that engines implement apparently simple commands is that they may constrain the engine to work in certain ways. Implementing lots of commands just because they are trivial in some implementations does not necessarily mean they will be easy in all possible implementations.
As I think I've mentioned before, it was a long, long time before gnugo implemented undo. The priority was on getting a strong go-playing engine rather than making a good user experience. Of course, it's different now...
It's not impossible to imagine an engine with so much complex state and cache information that undo is simply not possible, other than by going back and regenerating the moves from scratch.
Incidentally, I can't remember the current state of things, but IIRC, there were proposals to separate the commands to generate a move from committing that move. So the contoller would ask the engine for its move, then tell the engine later to place a move, which would usually be the move the engine asked for.
ISTR that one objection to *not* having undo was that it could destroy an engine's incremental state by clearing the board and playing all the previous moves.
However, could it not be argued that asking for the engine to make a move without allowing it to update its state has just the same effect ?
Apologies if you've all moved on from here...
And FWIW, one nice feature of the smtp/http response scheme is that you can distinguish success/temporary failure / permanent failure without needing to understand the text of the message. Just the first digit is enough. If we are using plain text responses, perhaps we should use a standard textual prefix (OK, WARN, ERROR, ...) in a similar way. So then even if the exact text of the response is not understood, the controller knows if the engine is reporting an error or not.
dd