I think that if we really do agree on four goals for GTP (playing games vs. other programs, automated testing, go server connections, and connection to a general purpose GUI) then there will be a significant number of commands that aren't used in playing games vs. other programs. For example:
* Automated testing should probably have commands to query the status of groups and set up board positions, asking for territory evaluations, etc. * Server connections will need a command to ask "is starting this game OK". * General purpose front ends would probably need commands similar to testing, for querying state of groups, setting go engine parameters, etc.
I don't see why we need to force a person who just wants to participate in GTP tournaments to implement the commands for these other purposes. Instead I think it would be easier for everybody to say "These are the commands you need for tournaments. These are options, only implement them if you plan on using them yourself."
Don Dailey wrote:
I would like to also point out that we CAN have a very complete set without it being "big" and involved or difficult to implement. A set was already sketched out that is very small, but makes it possible to design a full featured user interface.
By "full featured" I mean just all the basics, saving and loading games, positions, setting levels, taking back moves etc. Almost any highly advanced features can be composed by a user interface if we have the minimal support that I am asking for. Also, I don't want to be forced to add my own non-standard commands just to be able to do something really as basic and simple as taking back moves. How lame is that?
Don
-- Bill Shubert (wms@igoweb.org) http://www.igoweb.org/~wms/