It's in the very early draft stages. Gunnar sent me a list of changes today.
----- Original Message ----- From: "Hellwig Geisse" Hellwig.Geisse@mni.fh-giessen.de To: gtp@lists.lysator.liu.se Sent: Thursday, September 13, 2001 11:56 AM Subject: [gtp] GTP Specification-Draft
Hi folks,
I joined this mailing list only very recently, so please be patient with me if I missed one point or another in the preceding discussions.
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?
First of all, thanks for the hard work which already went into this document. But during my implementation work I ran into some questions which I want to discuss here.
- 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."
- The grammar as specified cannot be used to parse commands
because it is ambiguous in several places. Let me give an example: 'command-arguments' can be a 'command-argument' which in turn can be 'text'. 'text' consists of 'printable' characters. The hash "#" is a 'SYM' and therefore a 'printable' character. This is in conflict with its use as the character which starts a comment. By the way, the 'text' "a1" may as well be a 'coordinate' in a command argument and thus has two different derivations also. I see two possible solutions: 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 ... }).
- 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". c) A comment following a command argument must not be preceded by an 'SP'. Is this really intended? d) A command which solely consists of a command name may not be followed by a comment. Really?
- Another typo:
"The core command set consists of the following eleven (14) commands:"
- The error messages specified for various commands sometimes
include 'not_implemented' and sometimes they don't. What is the reason? This has apparently nothing to do with the different command sets: gen_move is in the core set and nevertheless may be answered with 'not_implemented'. By the way: is it spelled "gen_move" or "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 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.)
- 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? (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?'.)
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.
Regards, Hellwig _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp