On Mon, 2007-03-05 at 20:00 -0600, Matt Gokey wrote:
> I'm entering this discussion a bit late, but what about the following
> idea?
>
> Perhaps we could start from scratch and create the protocol we want
> with
> no compromises based perhaps on an async event message model - a
> model
> everyone probably is quite familiar with. It could move beyond ASCII
> messages on stdout and be designed for extensibility. Add all the
> common features we are looking for to really make a modern, robust
> and
> complete system. Since something like this would be a superset of
> GTP,
> a reference implementation of the new protocol could also include a
> proxy implementation of GTP using the new protocol. This would allow
> the best of both worlds - programs can continue to use GTP if they
> wanted, operating in a more constrained context than programs that
> implement and use the new protocol. Years into the future we won't
> have
> the baggage of GTP still as likely all programs would eventually move
> to
> the new standard.
>
> Just a thought...
>
> -Matt
Hi Matt,
There are two potential problems with this.
1. If you get too far away from the current GTP protocol,
it won't be accepted.
2. In either case, if you push for the new protocol you will
hurt the computer go community.
I don't pretend to know how likely these scenario's are, but it's
my fear.
If I WERE to do something from scratch, I would start with UCI from
the chess world and make only minor changes to make it more
appropriate for GO. Not because I'm also a chess programmer, but
because it's a fully tested protocol and because it rocks.
I would point out that the chess world has 2 main protocols, one
that wasn't really planned but evolved from the xboard/winboard
projects. This is still a problem - if you get a chess engine
and a chess user-interface you have to make sure they are compatible,
because some engines use only one or the other and some interfaces
use one or the other although most good interfaces try to work
with both. But I don't really want this to happen with computer
go. (Of course there is GMP, but it's not a serious contender
for a quality user interface.)
I also hate to break away from the gnu project - it's their good
work that has set the standard for GTP. I believe if they solve
this problem with some kind of asynchronous protocol and build it
into gnugo, it will be accepted.
- Don
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
