It does allow commands to be sent out of order. Imagine we have the following gtp commands:
genmove_black heartbeat show_thinking
A problem tester piece of software sents up a postion and then sends "genmove_black"
The engine goes into a long think cycle. Suppose the tester software wants to know if the engine is thinking or has died (or the connection is broken.) It can send the 'heartbeat' command and the engine should respond as soon as possible to this commands (even if it is still in the middle of a very long think cycle.)
The engine keeps thinking, but still can send a response to the heartbeat query.
Don
From: "Phil Garcia" PhilippGarcia@home.com
Thanks Anders for all the comments and questions.
From: "Anders Kierulf" anders@smartgo.com To: gtp@lists.lysator.liu.se Sent: Sunday, August 19, 2001 9:55 PM Subject: RE: [gtp] GTP Specification-Draft
Thanks to Phil for getting this written up, it's good place to start from. Below are various comments and suggestions, and lots of questions.
(1) Optional id
What's the purpose of these optional id numbers? As I understand it, the engine is simply echoing them, it can't base any of its decisions on these numbers. So how are they helping the controller program? How are these numbers used in GNU Go, and what would the protocol lose if these were removed from the standard?
I agree, these numbers seem to be useless in a requst/response type of protocol. Unless there is a really good reason for keeping them, I'm all for removing them. Existing GTP developers please speak up.
(2) Error messages
Page 5 states that the error message should return "not implemented". So it seems that this error message is standardized, but not others. I'd suggest we standardize a list of error messages, and make them single words, e.g. "not_implemented", "illegal_move", and "invalid_coordinate". Controllers may then be able to make smarter decisions depending on the error message returned.
Great idea! I suggested something similar, using error code numbers, but your suggestion is much better. I will add this to the GTP specification.
(3) Command sets
In my opinion, the tournament command set should be the core set. Every Go program should at least implement the commands necessary to play in a computer-computer tournament. We need to keep that command set simple enough that this is not a burden, but I don't see a benefit in splitting up the tournament and the core command set.
I need help here. How do we see a tournament being formed?
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp