OK, there were some good suggestions, here's take 2 on the GTP goals. My thoughts...
* I think a minimal command set is absolutely necessary, but I clarified the bullet for what most people seem to think is the need: tournaments. If we leave all things optional, I can see one programmer saying "Hmm, I don't ever do undos, I can leave that command out", then if in a tournament an undo is needed (due to operator error entering a move or some such), one of the programs is totally screwed. We 100% need to say "you MUST implement these commands to play in GTP tournaments." * I clarified many of the points to say more precisely what they mean. * I added "additional programs that would be nice but aren't necessary for GTP to be usable" because lots of people were suggesting programs they wanted to see written. * I left in the requirement for GMP vs. GTP tournaments. I also see this as necessary, because we don't want to force all old programs to get GTP front ends, and we want to let GMP and GTP programs participate in tournaments together. * A few items added that people recommended, such as have GMP be able to do general interfaces. (Seems like a really good idea, that way one front end can be used by several programs, letting programmers spend more time on their algorithm and less on front end programming.) * Some people were bringing up commands that they wanted, I left all them out of this document. That belongs in the spec, not in the goals document...I want the goals to be just what we want to do with GTP and what we need to do to be successful, not include info on how GTP will work.
Well that's enough babbling. Here's the next version of the goals document. Again, all comments are welcome! ************************ GTP Goals version 2
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 minimal command set that is exactly enough commands to play head to head tournament games, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement. 4. It should be possible to design software that gracefully deals with unimplemented GTP commands/features.
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.
************************
3. There must be a minimal command set that is exactly enough commands to play head to head tournament games, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement.
Then we are finished. The 4 commands are genmove_white, genmove_black, black and white. Everything else can be done by passing the proper commands line parameters to the program.
This means everything else is optional, the very thing you (and everyone else who responded) seemed to think was a bad idea.
If we don't start with something complete, I will end up making up my own private commands and no one else will be able to use my tools (and this will happen with everyone elses tools too.) Do you think this is really what our goal is?
If you are saying we do a complete optional set and just specify a subset as "the minimal set", then let's move on to defining the "real" set.
Don
From: "William M. Shubert" wms@igoweb.org
OK, there were some good suggestions, here's take 2 on the GTP goals. My thoughts...
* I think a minimal command set is absolutely necessary, but I clarified the bullet for what most people seem to think is the need: tournaments. If we leave all things optional, I can see one programmer saying "Hmm, I don't ever do undos, I can leave that command out", then if in a tournament an undo is needed (due to operator error entering a move or some such), one of the programs is totally screwed. We 100% need to say "you MUST implement these commands to play in GTP tournaments." * I clarified many of the points to say more precisely what they mean. * I added "additional programs that would be nice but aren't necessary for GTP to be usable" because lots of people were suggesting programs they wanted to see written. * I left in the requirement for GMP vs. GTP tournaments. I also see this as necessary, because we don't want to force all old programs to get GTP front ends, and we want to let GMP and GTP programs participate in tournaments together. * A few items added that people recommended, such as have GMP be able to do general interfaces. (Seems like a really good idea, that way one front end can be used by several programs, letting programmers spend more time on their algorithm and less on front end programming.) * Some people were bringing up commands that they wanted, I left all them out of this document. That belongs in the spec, not in the goals document...I want the goals to be just what we want to do with GTP and what we need to do to be successful, not include info on how GTP will work.
Well that's enough babbling. Here's the next version of the goals document. Again, all comments are welcome! ************************ GTP Goals version 2
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 minimal command set that is exactly enough commands to play head to head tournament games, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement. 4. It should be possible to design software that gracefully deals with unimplemented GTP commands/features.
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.
************************ --
Bill Shubert (wms@igoweb.org) mailto:wms@igoweb.org http://www.igoweb.org/~wms/ http://igoweb.org/%7Ewms/
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
Heck, we can skip "black" and "white" if we have the operator typing in opponent moves, so even smaller and simpler!
But you are being absurd. I think most people on the mailing list agree that there is some group of commands that will strike a good balance between easy to program and making tournament play simpler and less error-prone. Requiring the program operators to type in all the game parameters beforehand would (in my opinion) be too much hassle and too likely to go wrong, slowing down the tournament. Perhaps I should get rid of my "no more no less" comment. :-)
Don Dailey wrote:
3. There must be a minimal command set that is exactly enough commands to play head to head tournament games, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement.
Then we are finished. The 4 commands are genmove_white, genmove_black, black and white. Everything else can be done by passing the proper commands line parameters to the program.
This means everything else is optional, the very thing you (and everyone else who responded) seemed to think was a bad idea.
If we don't start with something complete, I will end up making up my own private commands and no one else will be able to use my tools (and this will happen with everyone elses tools too.) Do you think this is really what our goal is?
If you are saying we do a complete optional set and just specify a subset as "the minimal set", then let's move on to defining the "real" set.
Don
From: "William M. Shubert" wms@igoweb.org
OK, there were some good suggestions, here's take 2 on the GTP goals. My thoughts...
* I think a minimal command set is absolutely necessary, but I clarified the bullet for what most people seem to think is the need: tournaments. If we leave all things optional, I can see one programmer saying "Hmm, I don't ever do undos, I can leave that command out", then if in a tournament an undo is needed (due to operator error entering a move or some such), one of the programs is totally screwed. We 100% need to say "you MUST implement these commands to play in GTP tournaments." * I clarified many of the points to say more precisely what they mean. * I added "additional programs that would be nice but aren't necessary for GTP to be usable" because lots of people were suggesting programs they wanted to see written. * I left in the requirement for GMP vs. GTP tournaments. I also see this as necessary, because we don't want to force all old programs to get GTP front ends, and we want to let GMP and GTP programs participate in tournaments together. * A few items added that people recommended, such as have GMP be able to do general interfaces. (Seems like a really good idea, that way one front end can be used by several programs, letting programmers spend more time on their algorithm and less on front end programming.) * Some people were bringing up commands that they wanted, I left all them out of this document. That belongs in the spec, not in the goals document...I want the goals to be just what we want to do with GTP and what we need to do to be successful, not include info on how GTP will work.
Well that's enough babbling. Here's the next version of the goals document. Again, all comments are welcome!
GTP Goals version 2
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 minimal command set that is exactly enough commands to play head to head tournament games, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement. 4. It should be possible to design software that gracefully deals with unimplemented GTP commands/features.
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.
--
Bill Shubert (wms@igoweb.org) mailto:wms@igoweb.org http://www.igoweb.org/~wms/ http://igoweb.org/%7Ewms/
gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
From: "William M. Shubert" wms@igoweb.org
Heck, we can skip "black" and "white" if we have the operator typing in opponent moves, so even smaller and simpler!
But you are being absurd. I think most people on the mailing list agree that there is some group of commands that will strike a good balance between easy to program and making tournament play simpler and less error-prone. Requiring the program operators to type in all the game parameters beforehand would (in my opinion) be too much hassle and too likely to go wrong, slowing down the tournament. Perhaps I should get rid of my "no more no less" comment. :-)
Excuse me, but I thought you said:
3. There must be a minimal command set that is exactly enough commands to play head to head tournament games, no more no less!
Don
Don Dailey wrote:
3. There must be a minimal command set that is exactly enough commands to play head to head tournament games, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement.
Then we are finished. The 4 commands are genmove_white, genmove_black, black and white. Everything else can be done by passing the proper commands line parameters to the program.
This means everything else is optional, the very thing you (and everyone else who responded) seemed to think was a bad idea.
If we don't start with something complete, I will end up making up my own private commands and no one else will be able to use my tools (and this will happen with everyone elses tools too.) Do you think this is really what our goal is?
If you are saying we do a complete optional set and just specify a subset as "the minimal set", then let's move on to defining the "real" set.
Don
From: "William M. Shubert" wms@igoweb.org
OK, there were some good suggestions, here's take 2 on the GTP goals. My thoughts...
* I think a minimal command set is absolutely necessary, but I clarified the bullet for what most people seem to think is the need: tournaments. If we leave all things optional, I can see one programmer saying "Hmm, I don't ever do undos, I can leave that command out", then if in a tournament an undo is needed (due to operator error entering a move or some such), one of the programs is totally screwed. We 100% need to say "you MUST implement these commands to play in GTP tournaments." * I clarified many of the points to say more precisely what they mean. * I added "additional programs that would be nice but aren't necessary for GTP to be usable" because lots of people were suggesting programs they wanted to see written. * I left in the requirement for GMP vs. GTP tournaments. I also see this as necessary, because we don't want to force all old programs to get GTP front ends, and we want to let GMP and GTP programs participate in tournaments together. * A few items added that people recommended, such as have GMP be able to do general interfaces. (Seems like a really good idea, that way one front end can be used by several programs, letting programmers spend more time on their algorithm and less on front end programming.) * Some people were bringing up commands that they wanted, I left all them out of this document. That belongs in the spec, not in the goals document...I want the goals to be just what we want to do with GTP and what we need to do to be successful, not include info on how GTP will work.
Well that's enough babbling. Here's the next version of the goals document. Again, all comments are welcome!
GTP Goals version 2
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 minimal command set that is exactly enough commands to play head to head tournament games, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement. 4. It should be possible to design software that gracefully deals with unimplemented GTP commands/features.
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.
--
Bill Shubert (wms@igoweb.org) mailto:wms@igoweb.org http://www.igoweb.org/~wms/ http://igoweb.org/%7Ewms/
gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
--
Bill Shubert (wms@igoweb.org) mailto:wms@igoweb.org http://www.igoweb.org/~wms/ http://igoweb.org/%7Ewms/
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
On Sat, Aug 11, 2001 at 11:15:24PM -0700, William M. Shubert wrote:
OK, there were some good suggestions, here's take 2 on the GTP goals. My thoughts...
* I think a minimal command set is absolutely necessary, but I clarified the bullet for what most people seem to think is the need: tournaments. If we leave all things optional, I can see one programmer saying "Hmm, I don't ever do undos, I can leave that command out", then if in a tournament an undo is needed (due to operator error entering a move or some such), one of the programs is totally screwed. We 100% need to say "you MUST implement these commands to play in GTP tournaments." * I clarified many of the points to say more precisely what they mean. * I added "additional programs that would be nice but aren't necessary for GTP to be usable" because lots of people were suggesting programs they wanted to see written. * I left in the requirement for GMP vs. GTP tournaments. I also see this as necessary, because we don't want to force all old programs to get GTP front ends, and we want to let GMP and GTP programs participate in tournaments together. * A few items added that people recommended, such as have GMP be able to do general interfaces. (Seems like a really good idea, that way one front end can be used by several programs, letting programmers spend more time on their algorithm and less on front end programming.) * Some people were bringing up commands that they wanted, I left all them out of this document. That belongs in the spec, not in the goals document...I want the goals to be just what we want to do with GTP and what we need to do to be successful, not include info on how GTP will work.
Well that's enough babbling. Here's the next version of the goals document. Again, all comments are welcome!
GTP Goals version 2
Part I - Functional Requirements. These are the actions that our command list must allow go programs to perform.
- 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.
- Usable for regression tests on programs.
- Usable for playing go on a server.
- Usable to write full featured interfaces.
To me it seems as though the core requirements are #1 and #3. That's where interoperability is most clearly required, judging not just from the remarks on this list, but from where most of the protocol-related implementation effort has gone in the last 10 years or so.
I think #2 is much less important, although it might be a nice bonus. I'm a huge fan of regression tests, but I'm not sure that portable regression tests are vital. Also, I'm not sure that a variant of an interactive protocol is the best way to specify portable regression tests, as opposed to e.g. adding some tags to SGF to express things like "white's best play in this position is G8" and "black can kill white's group at C11 if he's komaster."
I'm a little worried about #4. What does it mean, above and beyond #1 and #3? What's the motivation for it? Do you want to be able to mix and match engines and high-quality, top-of-the-line interfaces, so e.g. a software vendor could write his interface once and then swap in a new engine periodically as technology changes?
If #4 just means that it's possible to run a GTP program under something like cgoban's human-vs.-GMP mode, then it's a good thing, and I'm not so worried about it, but then it also seems nearly redundant with #1 and #3. If "full featured" means more than that, then I'm worried, because * It looks as though #4 might be messier than all the others put together. Existing fully featured interfaces do things like marking all the squares that a program is thinking about, and interrupting a program's thoughts about the last command when the user changes his mind and commands something else. * It's not so clear what to standardize. Coming up with a good standard is hard but tractable when there's a lot of existing practice out there and you're standardizing on some sort of consensus about what's good. Coming up with a good standard by doing new design work is much trickier. (perhaps especially when it's new human interface design work..)
I've slapped together an alternative proposal, which follows. -----------------------------------------------------------------------
-- Requirements (a mishmash of functional requirements, implementation requirements, limitations of scope, and whatnot) --
1. The GTP protocol must run over an underlying protocol which is available on most hardware/software systems. The only serious candidates are TCP and serial cables. TCP is the primary target. Compatibility with serial cables would be a nice bonus, but it is not worth adding complexity for. In particular, since TCP already handles error detection and recovery, the GTP protocol will not try to handle error detection and recovery itself (as GMP did).
2. TCP is asymmetric: one program listens, another program connects. Thus, we'll probably have both client programs and server programs, and if two clients want to play, they'll need to have a server in the middle. This is considered an acceptable price to pay for the advantages of TCP. Note: 2a. Because we plan to pay this price, it's important that the minimal conforming server be extremely simple. 2b. If someone comes up with an elegant way to allow two clients to talk directly (with no intervening server) without requiring additional complexity, it'd be good to support that.
3. The protocol must be capable of transmitting the parameters describing the beginning of a match (e.g. color to play, size of board, and ruleset variant) and the state of an ongoing match (client's remaining time, opponent's remaining time, and perhaps other things that I haven't thought of). However, it must also be possible for a minimal conforming program to remain extremely simple by ignoring all this stuff, so that e.g. in a tournament where the program knows the initial parameters through another channel, and keeps track of its own time, the interface can be trivially simple and still conform.
4. The protocol must support proprietary or experimental extensions in a clean way. Programs should be able to use extensions without fear that they'll accidentally collide with other programs' extensions, and it should be possible for a program encountering an unfamiliar extension to decide whether it can safely ignore it.
5. Human-readability of the bare protocol is important, and conservation of bandwidth isn't important, so the protocol will be human-readable (unlike e.g. the old Go Modem Protocol, and like e.g. HTTP).
6. Minimal implementations are an important implementation goal, so unless there are extremely compelling advantages, the protocol won't be layered over anything much more complicated than TCP. Thus we will try to avoid requiring a conforming implementation to incorporate an XML parser, Unicode support, arbitrary precision integer support, multithreading, or anything else which isn't built into today's consensus minimal programming application programming environment.
7. In the spirit of point 6, the protocol should be easily implementable in terms of some 8-bit character set (UTF-8?). However, any parts of the protocol which are used to carry human-specifiable text should provide a way to encode Unicode. Thus, you shouldn't need Unicode support to implement the protocol, but the protocol should work gracefully when both sides do have Unicode support.
8. It should be possible to implement bridges/adaptors between the new protocol and old programs which speak the old GMP and IGS protocols. This doesn't mean that they have to have the same feature set, just that they can be adapted to the new protocol, much the way that they have already been adapted to each other (e.g. in cgoban).
9. In the spirit of point 8, GTP should try to provide enough hooks that an adaptor can handle operations which GMP and IGS use to help recover from problems, such as undo-a-move and restore-an-old-position operations. However, in the spirit of point 3, a minimal program should be able to ignore all of this and still conform.
10. Security is nearly a nonissue for this protocol. Any attempt to mess with the protocol is essentially denial of service. It's only likely to matter in an important tournament, and in that case it should only be available to people physically present, and the people physically present are trusted not to do denial of service attacks. (They're not searched for wire cutters when they enter, after all.) Also, in the longer term, it's my understanding that IPv6 makes it straightforward to run TCP securely, and as long as the GTP doesn't do anything really weird and stupid, it should remain as secure as the underlying TCP.
-- Auxiliary Programs --
The following example programs will be completed and tested on at least two kinds of systems (e.g. Microsoft Windows and Unix-compatible) before the standard is considered complete, and at least one version of each will be included with the standard.
1. A minimal client program that conforms to GTP and can play a legal game (similar to the goDummy program for GMP).
2. A minimal arbiter program, suitable for solving the problem of two clients which want to talk to each other. (It's intended that this will be only a few dozen lines of code. If not, the "client/server asymmetry is acceptable" design decision above might need to be revisited.)
3. A smarter client program which presents a (possibly very primitive) interface to a human, and presents a GTP interface to a GTP server, allowing a human to play against a GTP program. All of the problem recovery features described in point 9 above should be implemented here.
4. A smarter arbiter program, capable of controlling a tournament game, checking for illegal protocol messages, detecting illegal moves, keeping track of time, and perhaps other basic features as well.
5. A GMP-to-GTP adaptor to accept GMP i/o on one channel and produce GTP i/o on another channel, to allow a GMP program to interface to a GTP server as though it were a GTP program.
Each feature of the protocol will be implemented in at least one example programs. The set of example programs might be expanded to accommodate this. [E.g., I don't know much about the practicalities of making a program which does Unicode and runs everywhere. Thus, it might be that we end up with example programs 3a, which does Unicode, and 3b, which accommodates older/stupider environments by not doing it.]
It would also be valuable to have a bridge from GTP to IGS, but that's not an absolute requirement. [I've never worked with the IGS protocol, but I've heard it's a poorly specified mess, and I dimly remember the IGS authors asserting intellectual property claims to it as well, so it might be something that we don't want to commit to.]