Re: computer-go: gnugoclient 2.0

[Don Dailey <drd@xxxxxxxxxxxxxxxxxxxxx>]

   I've been wondering for a while : is it intended that
   there be a distinction between commands "not_implemented"
   and generic unknown commands ?

That was not my intent.  As you say, you must return "not_implemented"
for any command not understood.

   It is fair enough to reserve the syntax of 'undo',
   so that anyone who does implement it agrees on the
   parameters. But I'm not sure all engines should
   recognise it just so they can report a different
   message.

   But perhaps I've misunderstood the intention
   behind a "not_implemented" reply.

The truth  of the matter  is that  if we  define a minimal  set, and a
program does not honor this, then all  that happens is either that the
interface will break, or the interface will  be written in a forgiving
style so as to simple report that the program doesn't support it.

I guess it has to do with how minimal you really want to get.  I don't
believe we should define every bell and whistle, but I think we should
cover something this basic.



   > I discussed how undo should be implemented in GNU Go's gtp
   > with Gunnar today and he suggested a scheme that was simpler
   > than the one I was thinking of. I think it should be easy
   > to do. He wants to keep a stack of all moves that are
   > played, just as I did. While I wanted to also keep track
   > of captures, his idea was that if undo is called you just
   > go back to the beginning of the stack and play each move.
   > That should be fast enough.


   And even if an engine doesn't keep track of the moves,
   the driving program could use gtp commands to reset the
   state and replay the moves..?

It's my  opinion that  this would  be poor engineering,  a bad  way to
implement takeback.  This absolutely requires something in the minimal
protocol a lot  more complicated that "undo."  I'm  really against the
idea of requiring a GUI to perform this complicated operation in order
to trick a program into taking back a move.

Also, some programs will lose  important state if the position is just
reset as if  it's from a completely different  game.  Even though this
can be preserved by making  the engine more complicated, it's a pretty
ugly hack and  the goal is to simplify the  engine, not complicate it.
And what if  the engine is keeping a  log of the game?  Is  it to view
this a brand new position?

I do,  however, feel that we  should have a  setup feature documented,
even if not requiring it.  Perhaps  we should have an extended set and
a minimal set?

Don