Re: computer-go: gnugoclient 2.0

[Don Dailey <drd@xxxxxxxxxxxxxxxxxxxxx>]

   From: Heikki Levanto <heikki@xxxxxxxxxxxxxxxxx>

   On Fri, Aug 03, 2001 at 05:03:14PM -0400, Don Dailey wrote:
   > Whether a program has "undo"  or not isn't really  a big deal.  But in
   > my  opinion  the  real  issue  is  getting   this very  basic  feature
   > documented right away.

   A standard is complete not when there is nothing to add, but when there is
   nothing to remove!

Hi Heikki,

I am not   looking to be fashionably  minimal  and think  we would  be
making a mistake to throw out all commands not directly needed to play
a game, like "quit", "komi", "boardsize" and "version."

The goal is to have a small but practical set of commands.  This is an
engineering issue, not a  philisophical thing.  GTP is a communication
protocol designed  to support Go  engines talking  to  any kind of  Go
utility and  as  such  it's  almost ludicrous  to view   "undo"  as an
"advanced" command.

It doesn't take a great  deal of imagination  to see how powerful  and
useful such a command is, and yet so easy to implement.   

There was a  post a few weeks ago   about user interfaces that  I will
quote here, and it really  hits the nail on the  head.  In my opinion,
our standard  should be small, but big  enough to address the few very
basic issues this poster mentioned:

> now i want to mention how i got into that. it had nothing to do
> with playing go via a server, all i wanted to do is play against
> gnugo on my machine. you can do that with cgoban, but that does not
> let you continue to play a saved game. also whenever gnugo makes a
> particularly stupid move, i want to find out why and then i want to
> force gnugo to play another move. all this you can do with
> play_ascii, but that has a lousy display. so all i did was  ...

To me,  this is just  not right.  I can't see  going to the trouble to
define a standard that doesn't support any of this.

Am I being crazy or too optimistic?  How can anyone consider "undo" as
being an esoteric or highly advanced feature?

By the way, you did go on to consider  other possibilities like having
hierarchies of  sets and provisions for  ignoring commands.  Yes, this
is probably need at some  level, but I believe  it's important to make
sure  the  FIRST  basic standard draft   is complete  enough   to do a
reasonable job, and not a seriously crippled and limited subset of the
commands that people "really want."


Don