On Fri, Aug 10, 2001 at 07:39:46AM -0700, William M. Shubert wrote: [a proposed Goals/Requirements document]
I have 4 suggestions.
Part II - Implementation Goals. Constraints that we must follow when designing the exact command list.
- Simple to implement and debug; all ASCII.
- Possible to create bridges that let GMP programs play head to head vs. GTP programs.
- 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.
-- suggestion 1 --
Gunnar suggested three more commands: name, version, and protocol version. I'm not sure that all three are needed, but I think that protocol version, at least, is a sufficiently useful and simple thing that it belongs in essentially every protocol. (This seems to be the consensus of the RFCs I've seen.)
-- suggestion 2 --
I suggest one more command: out-of-band text. This could be useful for at least the following: * as a low-tech ("poor man's") replacement for Gunnar's "name" and "version" commands, plus some others like "event" * as a poor man's way of handling error conditions (Send a human-readable message as out of band text, then close the connection.) * as a poor man's way of handling stuff like kibitzing and direct opponent-to-opponent communication that occurs on servers E.g. out_of_band server round 1 white=plodder black=aya out_of_band client plod-2.0.520, 2001-08-10, rng seed 5824c103 out_of_band client error: can't understand GTP version 9, giving up out_of_band server *FATAL* illegal move 11a out_of_band server kibitz from "smith616" "g3 rahter tricky"
It is also very easy to implement an out-of-band text command, both in a minimal server and in a minimal client. A minimal server can just echo it. (I rather hope that "just echo it" can be a conforming server default implementation for nearly all commands.) A minimal client can either ignore it (if it's really really hard core minimal) or echo it to the screen/logfile/whatever. The only complexity I can see is how you delimit the text, but if you take care in specifying that (e.g., in a line-oriented protocol, requiring escape sequences for any line-breaking characters) you can allow arbitrary messages without increasing the minimal complexity of conforming servers and clients.
(Some might say that an out-of-band text command is also useful as a way of implementing some kinds of extensions, but IMHO that's more of an attractive nuisance than a feature. The first-step-up-from-minimal protocol should provide a way to add extensions, and it should be cleaner, e.g. defining a standard way for one implementation's extensions to avoid colliding with other implementations' extensions, and defining a standard way for an extension to say "It's safe to ignore me if you don't understand me.")
-- suggestion 3 --
I'm not sure that "no server" is a required case. The complexities of choosing a server and socket (that you'll listen on and your opponent will connect to, or vice versa), of communicating the server and socket to your opponent, and of making conforming client programs smart enough to handle sockets not only the connecting direction but also in the listening direction aren't overwhelming, but they're noticeable. Maybe we could dodge those complexities.
I'll renominate the target simple cases that I suggested on the main computer-go mailing list: * a minimal client playing where the rules, and everything else, are known by an outside channel. (E.g. in a computer Go tournament where you learned the rules, time controls, and so forth from the tournament organizer.) * a minimal server which doesn't know anything about the rules or anything else, basically just echoing stuff to and fro (and possibly recording what it echoes so that that some smarter entity can check it for legality later in case of dispute) I think it's very desirable that these be implementable very, very simply.
Then, if the minimal server can be done in e.g. two dozen lines of no-more-obfuscated-than-the-typical-Programming-Perl-example Perl, I think support for direct client-to-client communication could be unnecessary.
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).
- 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?
- A GMP-to-GTP bridge to allow GMP programs and GTP programs to play against each other.
-- suggestion 4 --
Regarding point 2 here: It would be good to provide a reference implementation of an arbiter which knows how to score a game, but as above, I really think it's even more important to support a trivial server which isn't an arbiter at all, but is as dumb as a box of rocks. Then ideally there should be at least two reference implementations. One reference implementation should be trivially stupid and simple and should take only 2 minutes to understand. The other can be reasonably smart and is capable of scoring, complaining about clients which don't conform to the protocol, and possibly doing other clever useful things as well.