Tanguy Urvoy has been advocating an extension to the GTP. The place for this discussion is the GTP list, not the GNU Go list.
The proposal being discussed is at:
http://www.irisa.fr/prive/Tanguy.Urvoy/gnugo/tanguy-3.1.15.1
See also
http://mail.gnu.org/pipermail/gnugo-devel/2001-November/000650.html
In http://mail.gnu.org/pipermail/gnugo-devel/2001-November/000656.html Tanguy wrote:
I admit that the list representation is good for certain things like listing the stones of a dragon or giving the list of best moves. I also admit that everything can be done with list of positions, but please also consider the other approach.
We can do three things:
(1) Disallow this change; (2) Allow it but consider it a GNU Go extension; (3) Allow it and make it to be part of the protocol.
Gunnar doesn't like this because it is inconsistent with the overall approach of the protocol. Also, Tanguy's reasons don't seem convincing to me. I'll comment on those below.
That said, there seems to be no real harm to exercising option (2) above, adding it but considering it a GNU Go extension. However that would mean that the client you write works with GNU Go but not other GTP engines.
However is (2) really an option? Other client writers will discover that by making a nonstandard protocol extension they can use GoThic which will create pressure to break the standard leading to a fragmented protocol.
I stated that Tanguy's reasons don't seem convincing.
- To keep a humand readable format.
(this is one the GOALS of GTP to be human readable and this is why people prefer C language to assembly language).
We can get an image of the board using the showboard command. It comes over stderr so as not to pollute the stdout channel. It does not show which moves are illegal, and that might be a nice extension. It is not designed for communicating with a client.
- To reduce the traffic in the pipe.
This was a goal with the gmp but never with the gtp.
- To use an easy to parse format (no need to use bison nor flex)
Both formats are very easy to parse. GNU Go does not use bison or flex to parse the GTP. You are talking about a few lines of C code.
- To use an easy to extend format
What extensions do you have in mind?
- To use a color independant representation of legal moves.
('.' is legal for all, 'x' only for black and 'o' only for white)
This point is somewhat valid. Basically the advantage I see to your format is that it makes it harder for the engine to produce inconsistent data. One might imagine a bogus engine returning a list of vertices to the commands list_stones_black, list_stones_white, all_legal_black, all_legal_white which do not represent a valid board. Tanguy's format would make inconsistent data easier to detect. But that doesn't seem an adequate reason to me.
Dan