Re: computer-go: Engineering (was: Most simple Go rules)

[Don Dailey <drd@xxxxxxxxxxxxxxxxxxxxx>]

   From: Christian Nentwich <c.nentwich@xxxxxxxxxxxxxxxxx>
   Organization: University College London
   Date: Wed, 27 Jun 2001 14:48:42 -0400
   X-Mailer: KMail [version 1.2]
   References: <000401c0fef6$f27afc10$093ba8c0@xxxxxxxxxxxxxxxxx>
   MIME-Version: 1.0
   Content-Transfer-Encoding: 8bit
   Sender: owner-computer-go@xxxxxxxxxxxxxxxxx
   Precedence: bulk
   Reply-To: computer-go@xxxxxxxxxxxxxxxxx
   Content-Type: text/plain; charset="iso-8859-1"
   Content-Length: 1283


   > I've never seen the GMP as a satisfactory solution. Wouldn't it be much
   > better to use a Go server as a tournament referee, having all the programs
   > communicate through TCP/IP? In straightforward cases, the server can run on

   This has come up before. The answer is noone is willing to invest time.

   The truth is, the methods used by go servers on the internet and GMP are 
   adhoc and horribly out of date. All of the problems discussed here can be 
   addressed by proper software engineering.  Martin Mueller wrote a paper a 
   while ago in which he pointed out the benefits of rigorous software 
   engineering as Go programs become large.

   Interfaces to servers could be in a standard interface format such as IDL or 
   even in XML. A simple middleware such as XMLRPC could be used for 
   communication (implementations exist for most programming languages in use 
   today). Interfaces and a unit test server could be defined and managed by a 
   group of individuals. Distribution would be hidden behind the middleware and 
   you could run your competition in any way you like, connection multiple 
   operating systems.

   The crucial point would be that a competent group of individuals (of which 
   there seem to be many on this list), retains tight control of interface 
   specification.

   Christian


I  would consider helping  if this was written  to be totally platform
independent,   and was  capable  of  full  game arbitration  including
scoring the final  outcome.   It would have  to  be able to score  the
final outcome accurately 100% of the time.    

Or is this illogical?

The protocol should be trivial  to implement in  any language and  not
require complicated  supporting  libraries, although  these  could  be
provided for convienence.


Don