From: William Harold Newman william.newman@airmail.net
On Fri, Aug 10, 2001 at 12:04:02PM -0400, Don Dailey wrote:
- There must be a minimal command set that is exactly enough commands to play head to head, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement.
I've thought a lot about this the last few weeks. I don't really see any need to define a bare minimal set. The programmers will implement anything they want anyway, we cannot or should not enforce this.
This might not be as good an approach as you think.
Ok, you have convinced me.
We have gone back and forth on this as a group which is why I relaxed my opinion of this. A bunch of people here don't think we need anything more than about 5 commands and seem to even resist it.
I think the common sense solution is to define a small, but COMPLETE set and encourage people to implement it in full. The point I was making is just that we cannot really stop people from being lazy or (too busy) to implement the whole set if they discover that they can do something they need to do with only 4 commands.
In my opinion, the only thing that will really make this work and make a protocol really successful is to build some killer software that needs the full set. No one is going to really give a hoot unless a killer interface motivates them to WANT to be compatible. If they have to ask, "why not just stick with GMP", then we are wasting our time.
So I agree, we should probably talk about this in terms of only 1 full set, you program either conforms to this particular standard, or it does not. The standard won't be too burdensome to implement, and we should provide a unit test utility that will determine if a program is fully conforming or not. This probably would motivate programmers to implement it, having a nice reference tool like this.
Don
It's my understanding (based on an explanation from David Fotland at this year's "21st Century Cup" computer tournament at the AGA) that the "specify everything, people will choose a subset anyway" approach has already been tried in Go protocols, with disappointing results. Implementing the complete Go Modem Protocol is enough of a hassle that some tournament (which he identified, but which I don't remember) encouraged people to implement a subset. That subset then took on a life of its own, and many programs implemented it. However, not all did. In particular, the third place finisher at the tournament, Wulu, had interoperability problems apparently -- again from David Fotland's description -- because it implemented the full spec instead.
(I'm not 100% sure that I understood the story correctly, because my program also attempted to conform to the full GMP, and my only interoperability problems were traceable to bugs in my code. But that doesn't necessarily contradict the story, since Wulu's problems only showed up when playing one color, and against a different (stronger:-) set of opponents than my program had. And anyway, whether or not it was at the root of Wulu's problems this year, it has apparently been a substantial problem in earlier tournaments.)
Also, it's been my experience that "it's too simple" is not the most common complaint that informed people have about a protocol once it's actually in use; and that furthermore, when excessive simplicity is the problem, it's often relatively easy to fix it in version N+1. Problems like "it's not interoperable" or "it's too unreliable" are common and harder to fix. Simplicity can help a lot in avoiding those problems.
"undo" is a good example. I don't care if someone chooses not to implement undo, the interface can simply report to the end user, in a graceful manner, that the engine doesn't support undo!
It's a lot better, in my opinion, to keep the whole set small and simple so that people are encouraged to do the whole set. As one person pointed out, we don't want to be stingy about commands like "version", since this is so trivial to implement that programmers will do it as a matter of course.
If the minimal conforming implementation is so simple that everyone implements it, that's good. Among other good things, the risk of incompatibility scenarios along the lines of the GMP problem above goes away. But to encourage that happy outcome to happen, I think it's wise to make the minimal conforming implementation very, very simple.
-- William Harold Newman william.newman@airmail.net "Be liberal in what you accept, and conservative in what you send." -- Jon Postel, RFC 1122 PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp