Fine. I have a tendency to over engineer things at times. But lets say that we're half way through a game and I need a command, one that we haven't encounted in our exchange, that I think is critical. When you return a "not implemented" to that command, my program quits and closes the connection. Wouldn't that be a terribly irritating experience? Maybe this scenario would be seldom encountered.
Thoughts?
-----Original Message----- From: William M. Shubert [mailto:wms@igoweb.org] Sent: Monday, August 20, 2001 10:28 PM To: GTP Mailing List Subject: Re: [gtp] GTP Specification-Draft
I agree with Gunnar, this seems needlessly complex. If I write GTP program, I'll provide a README telling users what commands they need. If they return "not implemented" to one of those commands, my program will either a) ignore this (if the command isn't terribly imporant) or b) quit and close the connection (if the command was critical). I'm definitely not going to spend my time writing my code to try to figure out whether or not the engine is "good enough" beforehand.
The only set of features that we need completely defined IMHO is the tournament features, because we want to be sure that everybody can play in the tournament before they get there. Otherwise, we can design commands with a use in mind (such as the "load SGF file" command used by a test system), but if somebody writes a test system that doesn't use the "load SGF file" command that's fine, and people who use that test system can just skip doing that command in their engines.
Alan wrote:
/ Well, I think that we may need commands where the machines can
/>/ announce to each other what command sets they support. Once that is />/ done, each machine will announce what command sets they intend to />/ use for that session. Maybe something like: / I don't see the need for this.
/ begin_command_sets_available
/>/ tournament />/ player_to_player />/ end_command_sets_available />/ begin_command_sets_used />/ tournament />/ end_command_sets_used />/ />/ or: />/ />/ begin_command_sets_available />/ tournament />/ player_to_player />/ end_command_sets_available />/ session_rejected />/ />/ if the machine does not wish to continue/ And this is just plain ugly.
/Gunnar
--
Bill Shubert (wms@igoweb.org) mailto:wms@igoweb.org http://www.igoweb.org/~wms/ http://igoweb.org/%7Ewms/
gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
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. The obvious exception, again, is tournament play, where you might not be able to connect to the exact system that will be used to run the tournament - which is why I think it is important that the tournament subset of GTP be given a separate grouping and all be required before you enter your engine into a GTP-based tournament.
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.
Cabrera, Alan wrote:
Fine. I have a tendency to over engineer things at times. But lets say that we're half way through a game and I need a command, one that we haven't encounted in our exchange, that I think is critical. When you return a "not implemented" to that command, my program quits and closes the connection. Wouldn't that be a terribly irritating experience? Maybe this scenario would be seldom encountered.
Thoughts?
-----Original Message----- From: William M. Shubert [mailto:wms@igoweb.org] Sent: Monday, August 20, 2001 10:28 PM To: GTP Mailing List Subject: Re: [gtp] GTP Specification-Draft
I agree with Gunnar, this seems needlessly complex. If I write GTP program, I'll provide a README telling users what commands they need. If they return "not implemented" to one of those commands, my program will either a) ignore this (if the command isn't terribly imporant) or b) quit and close the connection (if the command was critical). I'm definitely not going to spend my time writing my code to try to figure out whether or not the engine is "good enough" beforehand.
The only set of features that we need completely defined IMHO is the tournament features, because we want to be sure that everybody can play in the tournament before they get there. Otherwise, we can design commands with a use in mind (such as the "load SGF file" command used by a test system), but if somebody writes a test system that doesn't use the "load SGF file" command that's fine, and people who use that test system can just skip doing that command in their engines.
Alan wrote:
/ Well, I think that we may need commands where the machines can
/>/ announce to each other what command sets they support. Once that is />/ done, each machine will announce what command sets they intend to />/ use for that session. Maybe something like: / I don't see the need for this.
/ begin_command_sets_available
/>/ tournament />/ player_to_player />/ end_command_sets_available />/ begin_command_sets_used />/ tournament />/ end_command_sets_used />/ />/ or: />/ />/ begin_command_sets_available />/ tournament />/ player_to_player />/ end_command_sets_available />/ session_rejected />/ />/ if the machine does not wish to continue/ And this is just plain ugly.
/Gunnar
--
Bill Shubert (wms@igoweb.org) mailto:wms@igoweb.org http://www.igoweb.org/~wms/ http://igoweb.org/%7Ewms/
gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
-
Cabrera, Alan -
William M. Shubert