Hellwig wrote:
I am interested in implementing the Go Text Protocol (GTP) Version 2, for which I downloaded the draft spec revision 9. I assume this to be the most recent published one, right?
It's the most recent one but expect quite a few significant changes to the next one. To be perfectly honest it's a little early to do an implementation based on it yet.
- What kind of return (success or failure) does the engine
have to return if it does not implement the command which was requested? The spec says "..should return 'not_implemented'", but does not specify the return type (by the way, there is a typo in the section on failure: it must read "Here the '?' character..." instead of "Here the '=' character ..."). Only much later, in the section on error messages, one can guess that this return must be a failure return. I propose to phrase this sentence something like that: "Commands that are not recognized by the engine should return 'not_implemented' in a failure return."
Yes, it should definitely be a failure.
a) Cleanup the specification so that a parser for commands and responses can be generated by tools (e.g. flex & bison). I could do that, in case this is really wanted. This requires some extra work and I am not sure if it is worth the effort. b) Drop the attempt to formally specify the protocol. Use explanations in plain English instead. This is not as bad as it sounds, and it is used already in some places in the current spec (e.g., response-message = { depends on the ... }).
You're very welcome to help cleanup the grammar if you feel like it. I agree that an informal definition is preferrable to an inconsistent formal one.
- A few other grammar curiosities:
a) Where is 'WS' (white space) used? b) "date-time = date | date time" is missing an 'SP' between date and time. By the way: does 'SP' really mean a single space character? So one cannot, for example, separate two arguments with two spaces. Frequently, horizontal tabs ('\t') are also considered "white space".
It's probably asking for trouble not to allow multiple spaces and horizontal tabs, but I'm not certain about this.
c) A comment following a command argument must not be preceded by an 'SP'. Is this really intended?
No.
d) A command which solely consists of a command name may not be followed by a comment. Really?
No.
The idea is that everything from (inclusive) a hash sign to (exclusive) the following newline should be discarded on input, together with any occurence of CR.
By the way: is it spelled "gen_move" or "genmove"?
It should be genmove.
6.What is the exact format of the answer to 'help'? Specifically, is the first command returned on the same line as the '=' or on the next one?
It's returned on the same line.
- It is explicitly stated that coordinates and colors are case
insensitive. This does not hold for "yes"/"no" arguments in a suicide command, for example, nor for the argument of the 'scoring_system' command. What is the reason? (One can define this at will, of course, but IMHO consistency is a desirable goal.)
The suicide and scoring_system commands still need review. In the GNU Go implementation of GTP version 1 the case sensitivity only is important in the loadsgf command, since file names tend to be case sensitive.
- To write a competitive engine, the concept of time has to be
incorporated. Then the human opponent (or an arbiter in case of a computer tournament) has to fix the timing system. How should this be communicated to the engine?
Yes, this is important and missing. There has been some discussion about it on the list.
(Perhaps this goes under the "Tournament Command Set", or you have discussed it already; please enlighten me on this subject. The communication through command-line arguments during engine start-up is IMHO a non-solution because you open up a second way to transmit information to the program: the very next question is 'why not send <insert, e.g., boardsize here> in this way?'.)
I don't agree about this. While there should be provisions to communicate all important information through the protocol, I see no major problems with additional channels for setting up parameters. If some program has to be recompiled to switch between boardsizes that shouldn't disqualify it from being used in contexts where the boardsize is being known beforehand, e.g. a 13x13 tournament. For use on a server, on the other hand, such a limitation would be more problematic.
Please don't get me wrong: I do not want to exercise fault-finding on your specification draft. I only tried to implement things and I think that my experience could help to improve an already well- written document.
Your input is appreciated.
/Gunnar