Bill wrote:
For flexibility, specifying exactly where handicaps stones go means you can do handcaps not predicted in advance. For example, if you want to do h-5 on a 12x12 board, you don't need to specify as part of the protocol where exactly the 5th stone goes. This means that any handicap setup that an arbiter program wants to use can be done, no need to have the knowledge of this setup in the GTP programs. You can try fixed H-27 on a 19x19 and again, the program authors don't need to program in where all 27 stones go; you just make an arbiter than puts the 27 stones where you think they go, and then *any* GTP program will work fine - they just put the stones where they are told.
Another form of flexibility is working with other software. Different internet servers put handicap stones in different places. Specifying exactly where stones go in the protocol means you just can't play handicap games on all servers - even if you get it working on one server, on another you won't be compatible.
A last issue, not in flexibility but in removing potential (and probably likely) errors is the need for all GTP implementations to agree on where handicap stones go. The SGF protocol originally did this, and it turned into a nightmare because it was so hard to keep all programs in agreement. Yes, SGF specified that H-3 are placed at positions in corners "a", "b", and "c", leaving "d" blank, but it was so easy for programmers to accidentally leave "c" blank instead of "d", and it was so hard to detect until incompatible SGF files started floating around. SGF files now have "H-3, add black stones at these three locations", which is much easier
The free handicap commands place_free_handicap and set_free_handicap let you do exactly this, so I suppose you're just opposed to including a fixed_handicap command in the protocol?
So you would rather plan on deprecating a command than make the command extendible? Seems like a foolish decision to me. The nice thing about adding the "canadian" word now is that you don't have to maintain multiple time systems if you don't want to. If you only understand canadian time, and see "time_settings japanese 120 30 5", you just return an error, because you don't understand Japanese. If all GTP tournaments stay with absolute time controls (or canadian), then fine, people who only want to be in tournaments can write code that understands only "canadian" and "absolute". But if you want your client to be able to play against people using other time controls, it would be nice for the protocol to be able to cleanly allow client writers to do so. Deprecating a command and replacing it is *not* clean.
That was the worst case scenario. A cleaner solution is to just add a time_system command.
/Gunnar