Hi William,
This is a good start. You are right that not everybody is seeing this the same. That's to be expected and part of the process. I agree on building such a guideline document first as a focal point.
I'm going to suggest some changes to your document, based on my own "vision" of what I think GTP should be. Please let me explain my motivation first, and then people can critique this:
First of all, I personally am not very interest in a project that simply reimplements GMP (but uses text instead of binary codes.) In several posts I have noticed that people have not been very imaginative (and I'm not saying this to offend anyone) about what they expect out of GTP.
A careful reading of the posts, reveals clearly that many are stuck in the GMP mode which is this, "Carefully set up your engines beforehand to get all the playing options right and compatible, then let GTP pass moves back and forth."
There is nothing wrong with this model, but we already have this in GMP, right? This is not a step forward.
So in view of these things, I would suggest the following modification to your excellent first pass document:
********************************************************************* GTP Goals
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. 2. Usable for regression tests on programs. 3. Usable for playing go on a server. 4. Usable to write full featured user interfaces.
Part II - Implementation Goals. Constraints that we must follow when designing the exact command list.
1. Simple for clients to implement and debug; all ASCII. The standard GTP command set should be small (but not minimal.)
2. You can implement any subset of the "standard set" you wish, with the caveat that you may reduce the functionality of software than needs the unimplemented commands. The client must always return "not_implemented" in these cases.
3. Interface software, should be designed to gracefully accept the lack of not implemented 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. A general purpose user interface that excercises all the features of the standard set we design. (It shouldn't crash if a feature has not been implemented.)
2. An example program that implements the minimal GTP command set properly and can play a legal game (similar to the goDummy program for GMP).
3. An arbiter to be used in head-to-head games, communicating to both programs, judging legal/illegal rules, etc. The arbiter should know how to properly score the game.
4. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play against each other.
5. If feasible, a GMP to GTP wrapper. This is really a program that "converts" a GMP program to a GTP program, but of course can only represent a subset of the command set. With some creativity, we might be able to implement MOST of the command set by playing tricks like killing and restarting the engine with the correct options and so forth.
*********************************************************************
I left out a couple of things that you had in the document:
2. Possible to create bridges that let GMP programs play head to head vs. GTP programs.
Should that be a constrain? I don't want to be constrained by this even though I agree we should do this if it's possible (which I'm sure it is.)
3. There must be a minimal command set that is exactly enough commands to play head to head, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement.
I've thought a lot about this the last few weeks. I don't really see any need to define a bare minimal set. The programmers will implement anything they want anyway, we cannot or should not enforce this.
"undo" is a good example. I don't care if someone chooses not to implement undo, the interface can simply report to the end user, in a graceful manner, that the engine doesn't support undo!
It's a lot better, in my opinion, to keep the whole set small and simple so that people are encouraged to do the whole set. As one person pointed out, we don't want to be stingy about commands like "version", since this is so trivial to implement that programmers will do it as a matter of course.
Don
From: "William M. Shubert" wms@igoweb.org
Hello everybody. One thing that I haven't seen discussed yet is the exact goals of GTP. It probably seems obvious to everybody what these goals are, but perhaps not everybody's view is exactly the same, so I think it would be good if we could put together a goals document that we can all agree on. Then when we discuss features and commands, we can always refer back to the goals document and use it to help us decide whether or not these commands fit our goals well. Maybe we could even put the goals document on the "lists.lysator.liu.se" web site? In any case, it seems like it would be nice to have a place where more or less permanent documents that we have already agreed on are kept.
Anyway, here's my first attempt at a goals document. It's a combination of what I think are goals and what I have seen discussed here in the past week or so. ********************************************************************* GTP Goals
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. 2. Usable for regression tests on programs. 3. Usable for playing go on a server.
Part II - Implementation Goals. Constraints that we must follow when designing the exact command list.
1. Simple to implement and debug; all ASCII. 2. Possible to create bridges that let GMP programs play head to head vs. GTP programs. 3. There must be a minimal command set that is exactly enough commands to play head to head, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement.
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.
********************************************************************* So what does everybody think? Anything I left out/shouldn't have included/got wrong?
PS - Hopefully this message will make it to the mailing list in plain text - I think my mailer is set up properly, but I may have made a mistake that will make it send HTML mail. My apologies if this happens, I'll make sure to fix it if it does. --
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