Re: [gnugo-devel] GTP extension for passive GUI

[Daniel Bump]

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