This is not a protocol-thing. (and it does not need to be) This is a controller-thing.
I think this DOES need to be a protocol-thing and I respectfully disagree on this point.
Yes, it's easy to set up a match between any 2 programs playing independent levels, but the protocol in general is very weak with regard to building sophisticated controllers. I'm speaking from the point of view of standardized commands more than anything else but the synchronous protocol is a bit of an issue too.
Suppose you wanted to build a sophisticated GUI for all GTP based programs. How do you handle level settings?
You have a big README file where you explain to the user that to have levels you must set up different program identities - one for each possible level the user may want to use. If a program has infinite levels you tell the user they must choose a few among them or else set up a new identity when they want another level.
Even this is no solution because the levels must be advisory - in other words, unless the controller understands the time control setting, it cannot be enforced. The program can take as much time as it wants and you have to just trust that it's playing according to the time control you "hard coded" into the program invocation line.
Likewise with the end user. Since there is no standard way of specifying different types of time-control, unless you build an interface for a specific program with custom commands you are very limited.
In order to have matches where the time control is arbitrated, the controller must UNDERSTAND the levels that you "hard coded" into the program invocation line. This cannot be worked around except by managing time-control outside the protocol and the GUI - a very ugly situation.
You make it sound as if putting time-control in the protocol is a broken idea and the only natural way is to leave it out of the protocol. But this is backwards. The WHOLE concept of a protocol, as you yourself explain, is that there is a "controller", and presumably a "controller" should have control.
I think GTP works just fine - the author had the insight to make it extensible and most of the "issues" many have can be easily corrected with the addition of a few more commands.
I also think the author(s) of GTP did the right thing initially, they kept it real basic to start with instead of trying to throw in everything including the kitchen sink. But this should eventually be followed up with a few more standardized commands based on having a few years experience with the protocol. These additional commands should be carefully considered and kept to a minimum.
I understand why the GTP authors did not tackle time-control issues right away - it is probably a big can of worms. I'm wondering if there is a way to specify just about any kind of time control setting in a flexible way that is not too difficult to understand. But I am doubtful, I remember seeing discussions just trying to understand byo-yomi time where it was clear that it wasn't easy to understand if you are not already immersed in Go culture.
- Don
On Thu, 2007-08-23 at 10:52 +0200, A van Kessel wrote:
[Re=reply: the listserver does noet seem to set the Reply-to: header correctly ... ]
a special request : why not offer the possibility to set different time settings for each player ? again i think it would be fun
Te protocol is asymmetric. There is the engine at one side, and the controller at the other. For a game between two computer players, you need two GTP-"sessions", and one (or two) controllers driving them. There is no restriction on the (time-)settings for both players (the engines don't need to know the other's settings). So it is possible to create an uneven match. This is not a protocol-thing. (and it does not need to be) This is a controller-thing.
AvK _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp