[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: computer-go: Engineering (was: Most simple Go rules)
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