You make some good points Don. It seems that the implicit scenario here is that you will always thoroughly know your opponent's engine. Since this may currently be the case, especially in this small computer-go clique, then I see your point. Will that always be true?

For non-tournament play, it seems like pickup games will be the norm and hence this group's extended discussion about non-tournament commands. In this case, having a priori knowledge of your opponent's engine may not be reasonable.

I think that auto-negotiation would solve that. I guess what I'm really lobbying for is an auto-negotiation phase, using whatever protocol specification. This auto-negotiation phase is not needed for tournament play though.

Alan

-----Original Message----- From: Don Dailey [mailto:drd@supertech.lcs.mit.edu] Sent: Tuesday, August 21, 2001 9:27 AM To: adc@multex.com Cc: wms@igoweb.org; adc@multex.com; gtp@lists.lysator.liu.se Subject: Re: [gtp] GTP Specification-Draft

Hi Alan,

I seriously doubt this is actually a big problem. I would suggest that all GTP based tools document the commands they expect and what the affect those commands would have if they are not implemented.

Also, I would expect that most GTP based tools will not crash but simply do whatever is most appropriate and graceful.

I also agree with William about the relative importance of this. Really, you shouldn't attach an engine to something at the last minute without thorough testing if it's something really important. And if it's really important, such as a tournament autoplayer, it should be pretty well documented and hopefully freely available beforehand.

Don

From: "Cabrera, Alan" adc@multex.com Cc: GTP Mailing List gtp@lists.lysator.liu.se

...

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

---

gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp