FW: Communication between computer Go programs

[Peter.Smith@xxxxxxxxxxxxxxxx]

> From: Heikki Levanto [mailto:heikki@xxxxxxxxxxxxxxxxx]
> 
> : Rather than definitions of over-the-wire protocol what I 
> would hope for is a
> : simple API for a Go program to use when playing other Go programs.
> 
> I think we would need both. If we do not standardize what 
> goes over the
> wire, other programs may not be able to talk this language. 
> Remember that
> not all program(mer)s live in Windows environment, so 
> providing just a DLL
> is of little value to some of us. An open-source implementation, with
> well-defined interfaces both to the wire and to the program 
> sounds ideal to
> me. 
>

Windows and DLLs were examples.  I didn't mean to say Java and Linux and
others are not important which they are.

Agreed, without the low-level protocols two programs will not be able to
communicate.  The problem I have is that (like many others I assume) I have
had to implement GMP myself.  It is too low-level a protocol for every Go
program to have to implement.  I don't know of any way to fully test my
implementation on the one PC I use.

> : Perhaps you would need 8 functions to do the following:
> : 	o	Register / deregister program instance
> : 	o	Send / receive start of game
> : 	o	Send / receive move (sent as a SGF formatted string?)
> : 	o	Send / receive end of game
> 
> I am not sure of what the (de)register stuff is supposed to 
> do, something
> DLL-specific?
>

I was thinking of the registering as a way for the program instance to
indicate it was running and ready to receive start of game messages.  For
the GMP protocol this might not do anything.  For a CORBA based protocol it
might add you to a naming service?
 
> I would like to add
>    - for connections
>        o  Establish a connection to a server at a given address
>        o  Wait for a connection (at a given port)
>    - for human-human playing
>        o  send a comment  
>    - for go programming
>        o  send debug commands (and receive debug output) 
>           (same as comments above?)
>    - for go servers: various things, like lists of active 
> games, results,
>      etc. 
> 
> I would also like to point out the advantages of making the protocol
> extensible, so that new features can be added later. Of 
> course this will
> have to be designed in a way that programs can always 
> communicate with the
> minimal set of features, and ignore the stuff they do not know about.
> 
> 
> - Heikki
> 

For a general protocol those are all good features.  I was hoping for a
reduced protocol / API which would serve for two programs to communicate,
and be simple enough to be cheaply implemented.

Peter.