On Thu, Aug 16, 2001 at 02:22:57PM -0700, William M. Shubert wrote:
I also am working towards a goal here with GTP. I plan on writing a program to allow any GTP program to play on my go server (KGS). In addition, I have the experience of having written a fairly commonly used GMP utility program (CGoban).
I don't consider what I put into the goals document "fragmenting" the GTP protocol as much as "layering" it. So we have the base set, that everybody must implement because it is necessary to play tournament games easily (this set of commands would I imagine be very similar to the expressiveness of GMP), then we will have other commands not needed for tournament play but that will be needed by people who want to use a front end like yours or a server connection system like mine.
That's something that I'm receptive to. I've tried to write statements like "a conforming program can be trivially simple" with that in mind.
I'm not sure whether the time is ripe to standardize the layers above, though I could probably be convinced. (More about that below.)
Lots of go programmers already have their own front ends, and I imagine will be reluctant to do work that is useless unless they want to use a GTP front end. So I see this layering as helping to convince people to transition from GMP and custom front ends to GTP by making it easy to "get their feet wet" by doing the tournament GTP commands. Once they have that working, they can call it a day and keep their custom front end, or if they wish to later replace their front end or start using a GTP test system it will be easy because they will only have to add the extra commands needed by the GTP front end/test harness.
I'm still skeptical about the value of a full-featured portable UI protocol, for two reasons. First, I observe a wild menagerie of features in existing UIs, so many that it would be hard to standardize them. Second, I'm not sure that people will be all that interested in connecting their engine to many different UI programs. I'd expect instead that when you or Don Dailey or whoever write whizzy UI programs, you'll get a community of engine writers who tailor their program to your interface, including whatever extensions (colored highlighting, influence lines, commands to change the analysis level, commands to query the program about what it thinks of the status of a group..) you include. And then there's another community of people who're primarily interested in engines, and don't consider interfaces interesting (at least not until their engine is stronger), and can be pretty happy with something very minimal.
You [WMS] were at the tournament at the AGA Congress, and your observations may have matched mine: * About three programs (?) used GMP to talk with cgoban. (Normally my program does this too. I didn't do it at the tournament because I had trouble at the last minute getting cgoban to work with a real physical modem port under OpenBSD, even though it had worked with Linux two years ago; so at the tournament I ended up having my program talk directly to the modem port.) * The rest of the programs used various home-grown GUI interfaces, many of which did many different interesting, incompatible things, like indicating what they were thinking about during the game.
I'm 100% convinced that it's important to write the protocol so that it's easy to layer future extensions (for UI or other things) over it. I'm not 100% convinced that there is enough current need, or enough consensus on what will be needed in the future, that it's useful to standardize anything beyond what's used now.
And of course, I've even been skeptical of standardizing 'undo'. There's been one response to my question saying more or less "yes, I talk to servers now, and I want to be able to use 'undo', please standardize it." I'm not going to struggle too hard to stop people from standardizing it, but obviously, I don't think it's such an obviously good thing as Don Dailey does. My little use case for the Full Featured Go Server wasn't entirely serious, but there's a serious point that the interaction of undo with time systems could be less trivial than it looks. There could also be other feature interactions that we haven't thought of yet. If undo isn't actually being used, leaving it undone for now makes it easier to avoid being painted into a corner later. (And it also just makes the current standard a little simpler.)
I actually wouldn't have recommended this plan, but when I read the mailing list archives I saw people discuss a "minimal command set" that I interpreted this way, and it sounded like a great idea to me, so I have decided to run with it. If I misread the earlier emails and I'm the only one who likes this idea, fine, I'll take it out of the goals document, but I don't see how it would make GTP as a whole harder to implement correctly. It seems just the opposite, because people will be implementing only what they will be using, and features that aren't used in software are usually broken.
There's an important principle -- very simple conforming systems -- under here. I support it, but don't know how to express in a general or popular way. It can be achieved in several ways. "minimal command set" is one way. Another way is used in GMP to reduce the pain of the multifaceted QUERY command: a program can safely respond with 0 to any query. There are some dain-bramaged things about things about GMP, but I think the idea is sound.
Don Dailey wrote:
I thought we had earlier rejected the idea of multiple GTP command sets? It's just my opinion, but I think this would serve to discourage the adaptation of a standard.
William, I don't mean to be contentious about these issues, but I know that I am currently building a GOOD user interface and I will be making it available for EVERYONE to use. It will support "undo" and you will be able to set up positions from scratch and load problems.
So I'm speaking from a real NEEDS point of view, not a hypothetical "what kind of things might someone want to build" perspective.
I also know that one of two things will happen when I am done:
The new GTP standard will be powerful enough to support my UI.
The new GTP standard will need some extensions in order for OTHER programs to work with it.
I'm still going to build my interface in either case, but I will use my own extensions reluctantly, only if I have to. The extension I use will either be adapted anyone by others so they can use my interface, or someone else will build a more popular interface and have to build their own extensions.
As above, I think that portability and standardization for a UI program is less practical and less important than for a simple communications protocol. I doubt there's much consensus on this list about the features that your UI should have. And it's fairly reasonable for people to write a communications layer to talk to your UI, and only to your UI, whereas it's not reasonable for people to write a communications layer for each opponent they want to play against.