I'm not sure that you understood what I said; I am confused as to why you include a scenario where commands are to be simulated since I am not suggesting that at all.
Let me run through a sample scenario. It is not meant to be complete but is merely for expository purposes. I also want to add that we should have a common set of use cases that we agree on. Reading the archives of this group leads me to believe that we may not have a consensus on use cases.
The GTP group has sanctioned two official command sets. First, we start with a core feature set labeled "core". It will contain genmove_white, gen_move_black, white and black. Second, we have the feature set labeled "player_to_player". It will contain newgame, takeback, version, Level, and Setup.
Now your program supports core and player_to_player. My program only supports core. When we hook up to play we exchange supported sets and discover that we can only communicate via the core set. You've written a fancy interface telling the user that such and such commands are not available and ask if he/she wants to continue. The user does not wish to setup the board by hand and refuses the game.
Now, there's a guy named Joey who has a program who's engine only supports core but is very impressed by your program's interface and wants to support player_to_player like functionality. So, he simulates the player_to_player functionality, with the set core of commands, in his interface. Joey does this because he's stolen the engine from someone and is unable to modify it. :) (Is this what your talking about?)
Now, a guy named Bill comes up with six super-duper commands that has waiting rooms and allows chatting and mp3 files to be exchanged. He goes to the GTP group to have a new standardize set approved. The group gives his set the name "player_to_server".
Now you may want to upgrade your program to include this new set. Since I'm only writing a tournament machine, I will not. Joey, would like to include the player_to_server set of commands in his program but has yet to add an mp3 player to his set of warez; he chooses to not support it.
The critical key here is that we have GTP sanctioned sets.
You may say, Don, "Yes, yes, yes, we've discussed this before". However, anytime someone discusses leaving out a command that's near and dear to you, you bring up arguments that have no validity if we accept the above paradigm.
Regards, Alan
-----Original Message----- From: Don Dailey [mailto:drd@supertech.lcs.mit.edu] Sent: Wednesday, August 15, 2001 9:22 AM To: adc@multex.com Cc: gtp@lists.lysator.liu.se Subject: Re: [gtp] GTP Goals, ver. 3
Another footnote:
I suggested at one time that we just do a complete (but small) set and to let all commands be considered optional. This is pretty much the same idea. There are only 4 commands that you cannot manage to play a game with, genmove_white, gen_move_black, white and black.
Some other stuff can be faked with great effort by the interface builder, by carefully studying everything you can about each program you are building an interface for. Assuming we have only the 4 commands I mentioned, let's consider how we might do certain things:
newgame - kill the engine and restart.
takeback - kill the engine and feed back in all the game history.
version - build a configuration file that contains the programs with the version names.
Level - Have a configuration that understands the apropriate commands line arguments for setting various levels for various programs. If level is set during a game, kill the engine, reinvoke it with the correct command line arguments, feed back in the move to catch up to current position.
Setup - I'm not sure how easy this is to fake. You can place stones on the board to set up a position from a book or problem set, but you cannot be too arbitrary about the order you put the stones in, or you might accidently make an illegal move. You would probably end up with a program that could set up most positions, but people would notice that there were certain ones that cause it to crash, hang or simply reject.
Doesn't it seem silly that the interface builder should go through such superhuman efforts to build an interface everyone can use? If a new go engine comes along, the user must tediously create and careful test a large set of configuration options that are specific to the program being "interfaced."
In fact, why bother with GTP to do this? If GTP itself can't handle this why would I waste my time using GTP?
I don't need GTP to learn how each program works, wrap it up in my own shell and tediously configure a list of programs to work with it. GUI oriented programs will be harder but even this is doable, I used to do it with commercial chess programs so that I could autotest them against each other unsupervised. In involves trapping mouse or keyboard events, "reading" the screen in graphics mode etc.
So GTP is either a communication protocol or it isn't, and if it can't communicate then it's really a "could have been" thing, and people will stick with GMP (why would they change?)
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
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp