On Thursday 02 March 2006 10:01, A van Kessel wrote:

As Gunnar pointed out, there are some problems when (part of) the command fails. The natural choice would be to require atomicity: either the command succeeds and reports 'Ok' , or it fails *as a whole* and reports an error.

I agree.

(note: undoing an undo might be difficult)

I am not proposing that undo should be able to undo any command. Undo should undo exactly one move (or setup stone), undo_multiple <n> should undo exactly n moves (or setup stones).

As for the setup command: the main reason that I really need it are the silly SGF trees, that our Go engines create internally, if I transmit setup stones as play commands. It is intended to be an optional command, so if a Go engine cannot handle it, it simply shouldn't support it. Then the GUI can still fall back to sending setup stones as moves (with the mentioned problems), or simply refuse to attach a Go engine to a position that contains setup stones.

SGF is still the de-facto standard. This is not going to change any time soon. Even your GUI Quarry allows to add setup or remove stones at any position in the game tree. Why would you not allow to attach a Go engine to such a position? I can understand that a normal user mainly wants to play games with a Go engine. But a Go programmer needs to load SGF documents, attach his Go engine to it, and run different commands on the position.

- Markus