I have not been following this discussion closely, but let me throw few ideas in.
First about a new protocol --- I'm strongly against. I remember it was a real pain to force GTP over backward GMP. Now you want to force some (probably better but more likely more complicated) protocol over GTP which works and has many uses. I'd say you'll spend several years on this and yet it might not succeed. And it will most likely only hurt computer go community, not bring an advantage. About asynchronous move generation. I'd propose something like this. Add some form for asynchronous responses. E.g. '=[id] ...' means success, '?[id] ...' means error (this is as now) and '%[id] ...' means asynchronous response. Maybe for asynchronous commands it makes sense to make id mandatory. Responses must not be mixed, i.e. you cannot start a synchronous response inside asynchronous or vice versa (else they will be impossible to parse properly.) So, for old or not sophisticated engine it could look like this: 1 genmove white 2 best_so_far 3 abort_thinking =1 F14 ?2 unknown command ?3 unknown command But for engine with support for asynchronous responses: 1 genmove white 2 best_so_far 3 abort_thinking %2 D17 =3 ?1 aborted Clients can easily distinguish between two scenarios. To make it even easier, one can add one command: supports_async_protocol (optional command) -- returns 0 or 1, if not implemented, 0 is assumed by controllers and they may opt to never send commands meant to be replied asynchronously. Paul _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
