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