OK, Dan Dailey has convinced me. I will no longer speak in any way of a "minimal command set". Version 3 of my goals document instead calls it a "tournament command set", the plan being that if you want to use GTP for tournaments, you *must* implement all these commands, but all others are optional for tournament play. Do other people see this as a good change? It seems that most people who spoke of a minimal command set really meant "a command set if you just want to set up games and play them", but that seems still too vague, so I think "tournament command set" is a better way to put it. Dan, are you satisfied with this change? Or do you still have issues with having a subset of the commands being given different priority in this way?
Any thought or comments on this name change (or anything else in the goals document) are welcome. ******************** GTP Goals version 3
Part I - Functional Requirements. These are the actions that our command list must allow go programs to perform.
1. Usable to play games vs. other programs head to head. If the protocol requires some kind of arbiter, that's OK, but see III.1. 2. Usable for regression tests on programs. 3. Usable for playing go on a server. 4. Usable to write full featured interfaces.
Part II - Implementation Goals. Constraints that we must follow when designing the exact command list.
1. Simple to implement, debug and understand; all commands are ASCII, all human text (comments etc.) is UTF-8, exactly one line per command, each command gets an exactly one line response. 2. Possible to create bridges that let GMP programs play head to head vs. GTP programs in tournaments. Note that GTP and GMP will not necessarily have the same feature set - just the possibility of playing against each other is necessary. 3. There must be a "tournament command set" that is designed to be a small enough set of commands to be extremely easy to implement but complete enough to make go program tournaments efficient to operate. All commands needed only for regression tests, server play, or "full featured" front ends are optional extensions that programmers need not implement if they plan on using GTP only for tournaments. 4. It should be possible to design software that gracefully deals with unimplemented GTP commands/features when using GTP to communicate with other programs that have not implemented quite the same feature set.
Part III - Necessary Auxiliary Programs. These are programs that we (the GTP designers) must write for GTP to be successful. All must be open source.
1. An example program that implements the minimal GTP command set properly and can play a legal game (similar to the goDummy program for GMP). 2. An arbiter to be used in head-to-head games, communicating to both programs, judging legal/illegal rules, etc. Should the arbiter know how to score a game? 3. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play against each other.
Part IV - Additional Programs. These are programs that are not necessary for us to call GTP "done" but would be useful to have publicly available.
1. A sample GTP program that understands all of the commands. 2. GTP bridges for various servers. 3. GUIs and other human-usable front ends so that programmers who write GTP programs can automatically play against their programs, query their programs as to evaluations, etc. 4. A GTP test system/test library to determine whether or not a program is emitting legal GTP.
********************