Hi Rodrigue,
Your view of what the protocol should be like includes a lot of things rarely used in practice. There is no limit to the ways you could expand the protocol, but one has to ask how practical is it versus how much does it make the protocol unduly burdensome.
My biggest complaint has to do with synchronous nature of the protocol and I personally see GTP limitations in a completely different way than you do. It never once occurred to me that not supporting 27x27 boards is a serious limitation.
Your suggestions are not unreasonable however. The boardsize command could take 2 arguments, width and heights, and the coordinates could take integer arguments in place of actual Go coordinates.
But I doubt many consider these things very important. In many ways it would be a loss to see moves described as 3,3 instead of C3. In fact this is one of the complaints against SGF format, it's not very human readable.
Time control is a hairy issue. I too would like to see this added but it must be thought out very carefully. I would like to see it be flexible enough to express many different time systems without being difficult to implement.
Your ideas could be implemented as an extension of GTP. Boardsize could accept an optional 2nd argument and the moves could also be accepted in one of two formats. I would probably suggest that the definition of a move be expanded to include hyphenated coordinates. So you could send or accept C3 or 3-3 as a move (and 3,3 should probably be ok as long as there were no spaces.)
In other words some of your suggestions could be incorporated in such a way that there is total backwards compatibility. An old fashioned controller could work with the new abridged protocol. If you send boardsize that way too, I think you could use a modern controller with an old-fashion GTP program - it would just return an error if it didn't understand. So you could send "boardsize 19", "boardsize 19x19", or "boardsize 12x7" and older program would simply balk at the older usage.
All of these things can be implemented with 100% compatibility if you simple define new GTP commands - GTP is not short-sighted about this. So define your own boardsize and play command. The only problem with extended commands is that they are not standard.
- Don
On Tue, 2007-08-21 at 21:12 +0200, Rodrigue ASSARD wrote:
Dear list,
first of all, my intention is by any means to hurt anyone's feeling nor to start any flame war.
This said, IMHO i think this spec is a little shortsighted ...
Here are at least three reasons why :
1- the BOARD command should accept to create rectangular gobans... the question is why restrict it to square only ? I understand gtp is designed to enable testing on software programs ? then please let the possibility to foster some diversity... It would be good to see gnugo on a 4x7 board for instance :-)
2- "Boards larger than 25x25 are not supported by the protocol." Why ? Is it so complex to use another coordinate systems as 1,1 instead of A1 ? I know SGF has the same limitations, but why imposing such limitations ? is that another heresy to think about a 51x53 board ? played by two softwares for instance ? OK i'm definitely an heretic... for now :-)
3- the last but not the least concerns the time_settings. And here it's a special request : why not offer the possibility to set different time settings for each player ? again i think it would be fun to afford more time for gnugo than for myself. That would put more pressure on me...
ok i talk a lot about gnugo but i understand that the spec is tightly bound to gnugo or the opposite ...
Hope that i'm not off topic.
Best regards. Rodrigue.
gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp