Dear list,
here is a very long mail to Gunnar and i hope the contents is not just a pile of crap ... When rereading it, however, i feel i should have shut it in the first place. if you have time to waste... :-) (Sorry for the inconvenience, I think it shall be the last one on the subject)
GTPv2 WAS GOOD
i think GTP was a good thing back in the change of the millenium because it was giving more. GMP (Go Modem Protocol) was ruling and Gnugo brought a set of new possibilities that could be used by interfaces.
The spec was written and we hardly hear about GMP anymore. GTP is now a de facto standard. People like when they are given more.
WHAT'S THE SITUATION NOW
As GTP has been around for many years, even if published in draft, it is shaping either new go programs or UI programs.
GTP is a bottom-up specification that was spawn first to enable Gnugo to communicate with UI. In this respect, GTP should have been Gnugo Text Protocol... But altruistically, GTP manages to become Go Text Protocol. That move seems to provide all other would-be go programs a common base to work with.
We could still see the struggle between the two (go text protocol and gnugo text protocol) in sections 1.1 and 1.5 : 1.1 "The intention of GTP is to provide a flexible and easy to implement communication protocol for go programs ..." 1.5 "The reference implementation for GTP version 2 is GNU Go version 3.4 ..."
What is happening is that the implementation decisions that were made for Gnugo made their ways (naturally) in the spec thus shaping all the future go programs and UI programs to respect the Gnugo decisions. I consider this is a serious matter.
I don't say those decisions were bad. I say they are constraining. Maybe someone (say me) will ask for more and the spec will tell him : make your extension or do your silly stuff elsewhere. I think that the spec should now encompass a broader scheme.
When you say : "I could have included support for rectangular boards, huge boards, 3D boards, or go on general graphs but it's not worth the overhead having standard features that neither engine writers nor GUI writers have much interest in supporting.", I understand that GTP is Gnugo Text Protocol. I understand that Gnugo is the only one and always will be. I understand that all UI will have to be the same. I understand uniformity.
Don says : "Your view of what the protocol should be like includes a lot of things rarely used in practice." Yeah that's true. Should they never be implemented by any fool like me ? I think that if I don't ask for this features they will never ever be implemented by anyone. I would never ask any human to play silly games like 13x9. That would probably waste his/her time. And there is no such physical board on the loose. But when i play a software, i kind of like to ask it silly things. (you should study the real go games of pros instead you'll improve. yeah i know)
I'm asking for more. :-)
Perhaps because i'm a weak player, 10k on Igs, i talk about silly things like rectangular or giant board or asymmetric time settings. I first used Gnugo with Cgoban by Bill Shubert. Then i used Ggo by Peter Strempel. And from time to time i try other (free) interfaces : Jago, Gogui, etc. and still with Gnugo since it's the only free decent go program out there. What was not my surprise to see one day, gnugo resigned ! i said to myself 'wow nice feature! why ggo doesnt have it ?' i think it's because it had appeared in the draft at some time (response to genmove is vertex or "resign") and no renumbering had occured so that only new implementations had the feature ...
I think go programs can improve. I think UI can improve. I think a broader spec could do just that.
I think the umbilical cord should be cut between Gnugo and GTP. GTP should live by iself.
Gnugo should not be the reference implementation of GTP but an example implementation.
OH MAN YOU COULD SILLY-TALK, BUT WHAT DO YOU PROPOSE ?
I think it's time for GTP to adopt a top-down approach of what should a go program do, not just Gnugo. In fact, even Gnugo had evolved trying regularly to push surely the better in the spec. I think it's bad practice.
I totally approve Don's remarks concerning 'total backwards compatibility'.
I agree that GTP should provide a flexible communication protocol for go programs. But the spec should not limit itself to implementation constraints. It should be a diving suit for the happy programmer who'd like to throw himself in the (miry?) pool of creation. (i should ask my psy about that metaphor. should have a Freudian meaning of some kind)
It's the freedom of the implementor to limit the compliance to the specification. And the specification should provide a means for the go program to say what have been implemented. Who benefits ? The user because he runs the risk to have more options than the obvious and legitimate 9x9, 13x13 or 19x19...
I don't like much the idea of an extension because it corners what could be an interesting evolution of the spec in a single program or implementation. And perhaps someone will reinvent the same wheel again in its program over and over. Still, it seems to be a necessity somehow.
Then i suggest : - Freeze GTP v2 now ! tag everything as '[V2.x]' for instance. I think it is important to track the spec changes effectively. GTPv2 should be the core spec. Every go program should understand GTPv2. It's important that the commands created remain the same. Here we deal with 90% of today needs. - now let's tackle the go programs of the future : 1- a go program should be able to publish its capabilities. That way a UI program can query the caps and propose the user more choices. This is not the list of commands. A capability is the value enforced by a program on a featured aspect. Example I: for CasualGo (a would be go program) it could be: accept_square_board : true square_board_size_limits : 3-19 accept_rectangular_board : false accept_asymmetric_time_settings : false accept_tournament_minute_timer : false accept_undo : false
the initial query and response could be : casualgo> get_capabilities = square_board_size_limits accept_rectangular_board accept_asymmetric_time_settings accept_square_board accept_tournament_minute_timer accept_undo\n\n
then getting a capability could be : anygo> get_capability square_board_size_limits = 3-19\n\n
Example II : suppose BetterGo has the following: accept_square_board: true square_board_limits : 1- (oh my! who ever thought to play a 1x1 game? black always wins! :-) ) accept_rectangular_board : true rectangular_board_limits : 1- (oh no! he has lost it! a 1x19 game? how do you count that???) accept_asymmetric_time_settings : true accept_tournament_minute_timer : true accept_undo : true undo_limit : none (please, where can i find BetterGo? is it free?)
then setting asymmetric timer could be : bettergo> black_time_settings 10 10 25 = \n\n bettergo> white_time_settings 5 5 25 = \n\n
etc. Maybe the capabilities should be suffixed by _ro if they're read-only.
2- the spec shall live and every addition should tagged with the new number of the spec. A minor and a major. The spec should be proud to accept or ponder adding new stuff. It's its natural course : evolution. Perhaps the spec wants a lifting too : in the documentation, the commands are neatly categorized in admin, setup, core play, tournament, regression and debug. But the name of each command loses that categorization. too bad. why not using something prefixes like: - gtp_admin for admin - gtp_setup for setup and so on... to give : - for admin : gtp_admin_list_commands, gtp_admin_version, gtp_admin_protocol_version, etc. - for setup : gtp_setup_boardsize, gtp_setup_place_stone, gtp_setup_komi, etc. - for core play : gtp_play_play, gtp_play_genmove, etc. - etc.
Perhaps each command should have a verb indicating what is the action : gtp_admin_get_version instead of gtp_admin_version gtp_setup_set_komi instead of gtp_setup_komi gtp_play_do_play instead of gtp_play_play (play play please i'm waiting for your move, computer)
the benefits : commands following a norm, are more intuitive, talkative to a human, at no cost.
3- Perhaps the spec should indicate how the sequence of command needed to setup a game through an example : - identify the protocol used by the program anygo> gtp_admin_get_version ?\n\n (here it's definitely v2) anygo> protocol_version 2 - set the board size : anygo> boardsize 19 =\n\n etc.
or
anygo> gtp_admin_get_version = 3 1\n\n(oups did i really put two integers here?) anygo> gtp_admin_get_capabilities setup (query the program) = max_handicap_ro 9 accept_square_board_ro true accept_rectangular_board_ro false etc. (oh my you put all the keys and the values on the same line... it's in-mail optimization) anygo> gtp_setup_set_boardsize 19 23 (set board size) ?\n\n (oups) anygo> gtp_setup_set_boardsize 19 = 19x19\n\n (that's better) anygo> gtp_setup_set_handicap 5 = 5\n\n anygo> gtp_setup_set_komi 3.5 = 3.5\n\n anygo> gtp_setup_place_stones W C4 B D6 (setup initial stones if any) = 2\n\n anygo> gtp_play_do_genmove B = P13\n\n etc.
WELL CAN'T YOU JUST STOP ?
ok that's enough. That was my contribution to the subject. Odds are it will go directly to the paper basket... still, i had to try .
and perhaps the matter will re-emerge out of my twisted mind the day i decide to spend some time to create my UI... (oh my, where's that d... diving suite of mine?)
Best regards. Rodrigue.