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