Yes, this has been talked about much. Here is the general conclusion, although it's unclear if all agree:
. 2 standards are more complicated than 1, creates confusion.
. We already have GMP, we don't need a clone unless it's actually better somehow.
. We can still keep things very "minimal" and simple and have one complete standard.
We are not talking about hundreds of complicated commands, only about 12 or so, and they are trivial to implement. Probably the most complicated command I would like to see is "undo" (which apparantly many programmers find hard to do.)
Don
From: "Cabrera, Alan" adc@multex.com
Couldn't there be a bare bones standard with a set of standardized extensions? Each set of extensions could be standardized by this same group that is working on GTP. During the initial protocol negotiation, the set of extensions that each machine supports could be exchanged. Each machine would gracefully degrade in features available to the user, depending on what both machines were capable of.
Alan
-----Original Message----- From: Don Dailey [mailto:drd@supertech.lcs.mit.edu] Sent: Tuesday, August 14, 2001 5:02 PM To: dave.denholm@insignia.com Cc: gtp@lists.lysator.liu.se Subject: Re: [gtp] GTP Goals, ver. 3
Hi Dave,
Rather than making each user-interface add the composite commands, we could provide a separate (free) client-side library which implements high level commands out of the minimal commands provided by the protocol.
But this is not really possible unless GTP has enough primitives to support it. If there is no "setup" command, as an example, how do you set up a position? I absolutely agree with you however, we SHOULD be able to do these things.
You need a few basic primitives to do all the cool things. I am in favor of making sure we get them in a standardized set. If we don't, people (like me) will end up creating our own GTP extensions, and whoever builds the most popular user interface (or library like you are suggesting) will be the one actually defining the standard, in a defacto manner.
My user interface will actually have incredibly advanced features like the ability to set up a position or "take back" a move!!! I know how amazing that may seem to some, but I have this fear that I may have to create a non-standard GTP command to do these simple things. Since I will want other programmers to benefit from this, I'll have to communicate my extensions to the world, and the GTP "standard" itself will not really be treated as a standard or gain any respect.
You will get conversations like this:
Q "Hey, I want to implement the standard GTP protocol so I can use this super cool user interface I found on the web with my own program."
A "No, don't use the GTP standard, you can't really do anything very useful
with it except push moves back and forth between 2 programs. The best
set is the 'John Doe' set which most everyone else uses."
Q "But I heard the Bill Johnson set is better?"
A "Well, they are basically the same, but 'undo' is called 'takeback' and the Johnson set doesn't let you set levels except by editing the 'program invocation' box and adding the proper command line arugments."
Q "I just tried the John Doe set like you suggested, but it does't work."
A "Which user interface are you using?"
Q "I'm using the 'SuperGo tools' gui package."
A "Ok, that's a good one, but doesn't really work with the Doe set, I guess you have to use the Johnson set. By the way, there is a patch that let's you set levels by storing a library of different program invocation strings in a buffer and pressing the F7 function key to cycle through them."
... etc.
Don
From: Dave Denholm dave.denholm@insignia.com
Don Dailey drd@supertech.lcs.mit.edu writes:
> I would like to also point out that we CAN have a very complete set > without it being "big" and involved or difficult to implement. A set > was already sketched out that is very small, but makes it possible to > design a full featured user interface. > > By "full featured" I mean just all the basics, saving and loading > games, positions, setting levels, taking back moves etc. Almost any > highly advanced features can be composed by a user interface if we > have the minimal support that I am asking for. Also, I don't want to > be forced to add my own non-standard commands just to be able to do > something really as basic and simple as taking back moves. How lame > is that? >
Haven't really been keeping up, but...
Rather than making each user-interface add the composite commands, we could provide a separate (free) client-side library which implements high level commands out of the minimal commands provided by the protocol.
In fact, it could even do things like
if ( gtp_do_this_thing() == NOT_IMPLEMENTED ) { gtp_do_that_first_simple_thing(); gtp_do_that_second_simple_thing(); ... }
Eg if loading an sgf file is not implemented, the library can load it and send down lots of addstone commands.
(I'm not suggestinging this as part of a gtp interface library, but as a value-added separate layer...)
dd -- dave.denholm@insignia.com http://www.insignia.com _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp