Don Dailey wrote:
On Mon, 2007-03-05 at 10:10 +0100, Heikki Levanto wrote:
On Sat, Mar 03, 2007 at 04:10:16PM -0500, Don Dailey wrote:
And you CAN compare GTP directly to UCI because both are designed for
the same purpose and both are simple text based protocols and the
similarities are much greater than the differences.
GTP has many purposes. One of them is to sit betwene an engine and an
UI, but that is not the only one. It is also used for test scripts to
validate engines, and to debug them.
So, what even asynchronous extensions you are adding to GTP, please keep
the simple synchronous mode still available, for it has many uses too!
If I were designing the asynchronous extentions I was mandate that the
core doesn't change - that you can continue to use GTP as is without any
suprises.
I'm entering this discussion a bit late, but what about the following idea?
Perhaps we could start from scratch and create the protocol we want with
no compromises based perhaps on an async event message model - a model
everyone probably is quite familiar with. It could move beyond ASCII
messages on stdout and be designed for extensibility. Add all the
common features we are looking for to really make a modern, robust and
complete system. Since something like this would be a superset of GTP,
a reference implementation of the new protocol could also include a
proxy implementation of GTP using the new protocol. This would allow
the best of both worlds - programs can continue to use GTP if they
wanted, operating in a more constrained context than programs that
implement and use the new protocol. Years into the future we won't have
the baggage of GTP still as likely all programs would eventually move to
the new standard.
Just a thought...
-Matt
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
