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.
********************
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?
I have to say that I haven't been following that thread carefully.
I would give one reason for having a "minimal command set" which is that doing so is a big step towards standardization. But I have't reviewed the arguments against it. I'm travelling now and not reading my e-mail as carefully as I usually do.
Dan
I wrote:
I would give one reason for having a "minimal command set" which is that doing so is a big step towards standardization. But I have't reviewed the arguments against it. I'm travelling now and not reading my e-mail as carefully as I usually do.
Sorry, I wrote this too quickly. Going back and reading Don's message, I see that he is arguing against a proposed partitioning of a standard set of commands into a minimal set and a full set on the grounds that this would encourage nonstandard implementations.
With this in mind, my comment is wrong. Everyone is in agreement that the aim should be standardization, and I can see his point.
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?
I assumed that the last sentence was addressed to me but that "Dan" seems to be a typo. You were addressing this to Don Dailey.
Dan
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
From: Daniel Bump bump@match.stanford.edu Content-Type: text Content-Length: 1714
I wrote:
I would give one reason for having a "minimal command set" which is that doing so is a big step towards standardization. But I have't reviewed the arguments against it. I'm travelling now and not reading my e-mail as carefully as I usually do.
Sorry, I wrote this too quickly. Going back and reading Don's message, I see that he is arguing against a proposed partitioning of a standard set of commands into a minimal set and a full set on the grounds that this would encourage nonstandard implementations.
With this in mind, my comment is wrong. Everyone is in agreement that the aim should be standardization, and I can see his point.
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?
I assumed that the last sentence was addressed to me but that "Dan" seems to be a typo. You were addressing this to Don Dailey.
Dan
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
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/
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.
Who is it you are trying to be fair to? What about other users, they don't matter?
I'm not going to fight this battle any longer if others don't care either. I'll make up the commands if I have to and other programmers will have to conform to use my tools. It really isn't the way I want to do it, but I'm not going to write a user interface without the "position setup" feature or "undo" command just to name a couple.
Don
Sender: wms@supertech.lcs.mit.edu Date: Wed, 15 Aug 2001 21:40:43 -0700 From: "William M. Shubert" wms@igoweb.org X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-12 i686) X-Accept-Language: en-US, en, fr MIME-Version: 1.0 References: 200108141643.MAA03601@silk.supertech Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Content-Length: 1890
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/
Don, your comments are making less and less sense. I am merely putting out the point that since we plan on using GTP for several purposes, and some commands will be used for only some of these purposes, then it makes sense to break out the commands used for each purpose (eg tournaments) so that a programmer can implement only the commands they plan on using. What is so hard to understand about that? Why do you insist on anwsering my messages with bizarre tangents (like having to make up your own commands) that have nothing at all to do with what I was saying?
Don Dailey wrote:
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.
Who is it you are trying to be fair to? What about other users, they don't matter?
I'm not going to fight this battle any longer if others don't care either. I'll make up the commands if I have to and other programmers will have to conform to use my tools. It really isn't the way I want to do it, but I'm not going to write a user interface without the "position setup" feature or "undo" command just to name a couple.
Don
From: "William M. Shubert" wms@igoweb.org
Don, your comments are making less and less sense. I am merely putting out the point that since we plan on using GTP for several purposes, and some commands will be used for only some of these purposes, then it makes sense to break out the commands used for each purpose (eg tournaments) so that a programmer can implement only the commands they plan on using. What is so hard to understand about that?
My fault, I read that email in a big hurry.
I thought we had earlier rejected the idea of multiple GTP command sets? It's just my opinion, but I think this would serve to discourage the adaptation of a standard.
William, I don't mean to be contentious about these issues, but I know that I am currently building a GOOD user interface and I will be making it available for EVERYONE to use. It will support "undo" and you will be able to set up positions from scratch and load problems.
So I'm speaking from a real NEEDS point of view, not a hypothetical "what kind of things might someone want to build" perspective.
I also know that one of two things will happen when I am done:
1. The new GTP standard will be powerful enough to support my UI.
2. The new GTP standard will need some extensions in order for OTHER programs to work with it.
I'm still going to build my interface in either case, but I will use my own extensions reluctantly, only if I have to. The extension I use will either be adapted anyone by others so they can use my interface, or someone else will build a more popular interface and have to build their own extensions.
Don
Why do you insist on anwsering my messages with bizarre tangents (like having to make up your own commands) that have nothing at all to do with what I was saying?
Don Dailey wrote:
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.
Who is it you are trying to be fair to? What about other users, they don't matter?
I'm not going to fight this battle any longer if others don't care either. I'll make up the commands if I have to and other programmers will have to conform to use my tools. It really isn't the way I want to do it, but I'm not going to write a user interface without the "position setup" feature or "undo" command just to name a couple.
Don
--
Bill Shubert (wms@igoweb.org) mailto:wms@igoweb.org http://www.igoweb.org/~wms/ http://igoweb.org/%7Ewms/
I also am working towards a goal here with GTP. I plan on writing a program to allow any GTP program to play on my go server (KGS). In addition, I have the experience of having written a fairly commonly used GMP utility program (CGoban).
I don't consider what I put into the goals document "fragmenting" the GTP protocol as much as "layering" it. So we have the base set, that everybody must implement because it is necessary to play tournament games easily (this set of commands would I imagine be very similar to the expressiveness of GMP), then we will have other commands not needed for tournament play but that will be needed by people who want to use a front end like yours or a server connection system like mine. Lots of go programmers already have their own front ends, and I imagine will be reluctant to do work that is useless unless they want to use a GTP front end. So I see this layering as helping to convince people to transition from GMP and custom front ends to GTP by making it easy to "get their feet wet" by doing the tournament GTP commands. Once they have that working, they can call it a day and keep their custom front end, or if they wish to later replace their front end or start using a GTP test system it will be easy because they will only have to add the extra commands needed by the GTP front end/test harness.
I actually wouldn't have recommended this plan, but when I read the mailing list archives I saw people discuss a "minimal command set" that I interpreted this way, and it sounded like a great idea to me, so I have decided to run with it. If I misread the earlier emails and I'm the only one who likes this idea, fine, I'll take it out of the goals document, but I don't see how it would make GTP as a whole harder to implement correctly. It seems just the opposite, because people will be implementing only what they will be using, and features that aren't used in software are usually broken.
Don Dailey wrote:
I thought we had earlier rejected the idea of multiple GTP command sets? It's just my opinion, but I think this would serve to discourage the adaptation of a standard.
William, I don't mean to be contentious about these issues, but I know that I am currently building a GOOD user interface and I will be making it available for EVERYONE to use. It will support "undo" and you will be able to set up positions from scratch and load problems.
So I'm speaking from a real NEEDS point of view, not a hypothetical "what kind of things might someone want to build" perspective.
I also know that one of two things will happen when I am done:
The new GTP standard will be powerful enough to support my UI.
The new GTP standard will need some extensions in order for OTHER programs to work with it.
I'm still going to build my interface in either case, but I will use my own extensions reluctantly, only if I have to. The extension I use will either be adapted anyone by others so they can use my interface, or someone else will build a more popular interface and have to build their own extensions.
Don
Why do youinsist on anwsering my messages with bizarre tangents (like having to make up your own commands) that have nothing at all to do with what I was saying?
Don Dailey wrote:
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.
Who is it you are trying to be fair to? What about other users, they don't matter?
I'm not going to fight this battle any longer if others don't care either. I'll make up the commands if I have to and other programmers will have to conform to use my tools. It really isn't the way I want to do it, but I'm not going to write a user interface without the "position setup" feature or "undo" command just to name a couple.
Don
--
Bill Shubert (wms@igoweb.org) mailto:wms@igoweb.org http://www.igoweb.org/~wms/ http://igoweb.org/%7Ewms/
On Thu, Aug 16, 2001 at 02:22:57PM -0700, William M. Shubert wrote:
I also am working towards a goal here with GTP. I plan on writing a program to allow any GTP program to play on my go server (KGS). In addition, I have the experience of having written a fairly commonly used GMP utility program (CGoban).
I don't consider what I put into the goals document "fragmenting" the GTP protocol as much as "layering" it. So we have the base set, that everybody must implement because it is necessary to play tournament games easily (this set of commands would I imagine be very similar to the expressiveness of GMP), then we will have other commands not needed for tournament play but that will be needed by people who want to use a front end like yours or a server connection system like mine.
That's something that I'm receptive to. I've tried to write statements like "a conforming program can be trivially simple" with that in mind.
I'm not sure whether the time is ripe to standardize the layers above, though I could probably be convinced. (More about that below.)
Lots of go programmers already have their own front ends, and I imagine will be reluctant to do work that is useless unless they want to use a GTP front end. So I see this layering as helping to convince people to transition from GMP and custom front ends to GTP by making it easy to "get their feet wet" by doing the tournament GTP commands. Once they have that working, they can call it a day and keep their custom front end, or if they wish to later replace their front end or start using a GTP test system it will be easy because they will only have to add the extra commands needed by the GTP front end/test harness.
I'm still skeptical about the value of a full-featured portable UI protocol, for two reasons. First, I observe a wild menagerie of features in existing UIs, so many that it would be hard to standardize them. Second, I'm not sure that people will be all that interested in connecting their engine to many different UI programs. I'd expect instead that when you or Don Dailey or whoever write whizzy UI programs, you'll get a community of engine writers who tailor their program to your interface, including whatever extensions (colored highlighting, influence lines, commands to change the analysis level, commands to query the program about what it thinks of the status of a group..) you include. And then there's another community of people who're primarily interested in engines, and don't consider interfaces interesting (at least not until their engine is stronger), and can be pretty happy with something very minimal.
You [WMS] were at the tournament at the AGA Congress, and your observations may have matched mine: * About three programs (?) used GMP to talk with cgoban. (Normally my program does this too. I didn't do it at the tournament because I had trouble at the last minute getting cgoban to work with a real physical modem port under OpenBSD, even though it had worked with Linux two years ago; so at the tournament I ended up having my program talk directly to the modem port.) * The rest of the programs used various home-grown GUI interfaces, many of which did many different interesting, incompatible things, like indicating what they were thinking about during the game.
I'm 100% convinced that it's important to write the protocol so that it's easy to layer future extensions (for UI or other things) over it. I'm not 100% convinced that there is enough current need, or enough consensus on what will be needed in the future, that it's useful to standardize anything beyond what's used now.
And of course, I've even been skeptical of standardizing 'undo'. There's been one response to my question saying more or less "yes, I talk to servers now, and I want to be able to use 'undo', please standardize it." I'm not going to struggle too hard to stop people from standardizing it, but obviously, I don't think it's such an obviously good thing as Don Dailey does. My little use case for the Full Featured Go Server wasn't entirely serious, but there's a serious point that the interaction of undo with time systems could be less trivial than it looks. There could also be other feature interactions that we haven't thought of yet. If undo isn't actually being used, leaving it undone for now makes it easier to avoid being painted into a corner later. (And it also just makes the current standard a little simpler.)
I actually wouldn't have recommended this plan, but when I read the mailing list archives I saw people discuss a "minimal command set" that I interpreted this way, and it sounded like a great idea to me, so I have decided to run with it. If I misread the earlier emails and I'm the only one who likes this idea, fine, I'll take it out of the goals document, but I don't see how it would make GTP as a whole harder to implement correctly. It seems just the opposite, because people will be implementing only what they will be using, and features that aren't used in software are usually broken.
There's an important principle -- very simple conforming systems -- under here. I support it, but don't know how to express in a general or popular way. It can be achieved in several ways. "minimal command set" is one way. Another way is used in GMP to reduce the pain of the multifaceted QUERY command: a program can safely respond with 0 to any query. There are some dain-bramaged things about things about GMP, but I think the idea is sound.
Don Dailey wrote:
I thought we had earlier rejected the idea of multiple GTP command sets? It's just my opinion, but I think this would serve to discourage the adaptation of a standard.
William, I don't mean to be contentious about these issues, but I know that I am currently building a GOOD user interface and I will be making it available for EVERYONE to use. It will support "undo" and you will be able to set up positions from scratch and load problems.
So I'm speaking from a real NEEDS point of view, not a hypothetical "what kind of things might someone want to build" perspective.
I also know that one of two things will happen when I am done:
The new GTP standard will be powerful enough to support my UI.
The new GTP standard will need some extensions in order for OTHER programs to work with it.
I'm still going to build my interface in either case, but I will use my own extensions reluctantly, only if I have to. The extension I use will either be adapted anyone by others so they can use my interface, or someone else will build a more popular interface and have to build their own extensions.
As above, I think that portability and standardization for a UI program is less practical and less important than for a simple communications protocol. I doubt there's much consensus on this list about the features that your UI should have. And it's fairly reasonable for people to write a communications layer to talk to your UI, and only to your UI, whereas it's not reasonable for people to write a communications layer for each opponent they want to play against.
Bill Shubert wrote:
GTP Goals version 3
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. 2. Usable for regression tests on programs. 3. Usable for playing go on a server. 4. Usable to write full featured interfaces.
This depends on what is meant by full featured. As other people have discussed it's unreasonable to hope that a protocol like this could ever do all the fancy things that many programs have in their native interfaces. But if we're talking about a more limited interpretation of "full featured", and there seems to be some consensus about this, it's a worthwhile goal. Well, my point is that this needs some clarification.
Part II - Implementation Goals. Constraints that we must follow when designing the exact command list.
- 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.
No, one line responses do not suffice. This is why the protocol specifies a double newline to finish the response.
- 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.
- 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?
Scoring in the arbiter is not critical.
- 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.
- A sample GTP program that understands all of the commands.
- GTP bridges for various servers.
- 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.
Except for my comments, I'm happy with this.
/Gunnar
This depends on what is meant by full featured. As other people have discussed it's unreasonable to hope that a protocol like this could ever do all the fancy things that many programs have in their native interfaces. But if we're talking about a more limited interpretation of "full featured", and there seems to be some consensus about this, it's a worthwhile goal. Well, my point is that this needs some clarification.
Yes, we can always come up with new fancy features. In a very general way I personally consider "full featured" to be those features that "most good" programs would have in common. Being able to set the hash table size is NOT something I would consider part of this, as an example. Taking back moves, and setting up new positions would definitely be some of these features as well as setting the playing level or the ruleset to be played by. I would suggest not getting real fancy but sticking with the basics. The interface itself can get quite elaborate without that much coopoeration from the engine or protocol.
Scoring in the arbiter is not critical.
And this is an example of this. Scoring in the arbiter is not a GTP protocol issue. The decision to make an arbiter program actually do scoring is up to the arbiter software designer. (Someone is bound to suggest that a 3rd program could be the arbiter. Yes this could be done with GTP.)
Don
-
Daniel Bump -
Don Dailey -
Gunnar Farneb�ck -
William Harold Newman -
William M. Shubert