> From: William M. Shubert [mailto:wms@igoweb.org]
>
> Yes, this will be irritating. But that's why, if you choose not to
> implement every GTP command, you should run a few tests when
> you first
> attach your engine to a new GTP system to ensure that you support all
> the commands needed. Then you do the "real" work with it.
Well here's where we get to the crux of my point. I'm not wedded to that
particular protocol snippet, I just have a feeling that we're glossing over
an important, albeit boring, aspect of this protocol. When you say "you
should run a few tests when you first attach your engine to a new GTP system
to ensure that you support all the commands needed", I say fine, but the
devil is in the details and I want to know how exactly this gets done.
> I see your point, I just think that the handshaking you proposed will
> add a significant complexity and will probably be just as
> error-prone as
> the "try it and see" system I recommend...I know that were I to
> implement this system, I'd probably find my bugs in the
> "main" GTP part
> pretty quick, but it would be easy to screw up the
> protocol-checking and
> never notice since it wouldn't get exercised in as many different
> situations.
I don't see where it's more error prone, at least no more so than any other
command; we're not talking TCP/IP here. All you have to do is exchange the
hand full of command set names and move on.
Now let me first state this, not everyone is going to implement the full
porotocol; that much is clear from what I've been reading here. To me this
implies that I have a valid concern here. With that said, let me go over a
use case. If the case isn't relevant, please chime up.
We hook up, I run through a all of commands that I want to use to see which
ones you support. Now through dumb luck, I happen to run through a valid
sequence one quarter of the way through when I present a command that you
don't support. You return a "not implemented". By the time we're done, I
have to keep track of all those little commands that you don't support; this
is quite a complex endevor. Your machine and my machine are in a wacky
state, because of the testing. You may have even succeeded in crashing my
machine by sending in that one non-sensical sequence required to put me into
a bad state.
Now what if we just exchanged the two or three command set names? In my GTP
implementation, I'm asumming my protocol, there would be two or three
command handler classes, one for each command set. If there's a command set
that you don't handle, I de-register that command set handler.
Now someone may say, "My gift to the computer go community shall be a GTP
implementation that will handle all these minor points." I would reply, at
some point, my engine will still need to keep track of what commands and
features it can use/support and which ones it can't. Using named command
sets simplifies this tracking.
So my point is that for every non-tournement hookup, almost everyone will
*have* to do this to see what commands they can use. It's a grey area that
I think needs to be cleared up with me being partial to my proposal.
Alan