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. 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 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.
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.
Don
Why do you
insist on anwsering my messages with bizarre tangents (like having to make up your own commands) that have nothing at all to do with what I was saying?
Don Dailey wrote:
I don't see why we need to force a person who just wants to participate in GTP tournaments to implement the commands for these other purposes.
Who is it you are trying to be fair to? What about other users, they don't matter?
I'm not going to fight this battle any longer if others don't care either. I'll make up the commands if I have to and other programmers will have to conform to use my tools. It really isn't the way I want to do it, but I'm not going to write a user interface without the "position setup" feature or "undo" command just to name a couple.
Don
--
Bill Shubert (wms@igoweb.org) mailto:wms@igoweb.org http://www.igoweb.org/~wms/ http://igoweb.org/%7Ewms/