Łukasz,
Yes, I would like to see some of these problems solved.
As I mentioned, UCI doesn't have any of these issues.
After thinking about this, there is perhaps a backwards
compatible solution:
1. Don't change GTP, just add to it.
2. Have a command called "asyncronous" which tells the engine
that it supports the new "asyncronous" protocol. (Or maybe
the response to the protocol_version command is enough)
3. If the engine suports this, then it can accept
commands like "stop_search" and it can send certain
informational commands.
If the controller is asyncronous, the engine could still SEND
informational commands even if it was not capable of ACCEPTING
commands out of order.
You could get all the benefits of UCI without breaking backward
compatibility.
One issue is that the engine canont assume the more advanced GTP
protocol, it must remain in backward compatible mode (should not
send informational messages) unless that is directed by the
controller.
One way around this is to define a different set of commands
that are designed to be asyncronous. Then the engine can feel
free to accept or reject them. For example instead of using
genmove, the new protocol could send "begin_search", which
is understood to be an asymetric command. If your program
gets a begin_search command it is allowed to send informational
messages while searching. Those informational messages must
be specified by the protocol and contain information such as
nodes searched, score, current best move, search depth, etc.
But the program doesn't have to send information it doesn't want
to. If your program doesn't do a search it is not required to
send a search depth, etc.
If your engine accepts and responds to begin_search it is
understood that it will accept and respond to "stop_search"
- Don
On Thu, 2007-03-01 at 13:22 +0100, Łukasz Lew wrote:
> Hi,
>
> There are some issues that are not so well defined in GTP v2.
> Maybe GTP v3 should be released to avoid too much legacy later?
>
> 1.
> The most important thing is controller - engine architecture.
> There are situations that engine would like to have the control. For instance
> When he want to send commands to GUI to draw something while he is working.
>
> In gogui this is solved by using stderr to send those commands, but:
> - stderr is not network transparent
> - syntax is not standardized
> - there is no confirmation about success / failure for those commands.
>
> 2.
> The second thing is that there are many variables in the engine (komi,
> board size, time, etc).
> Developers tend to have more of them to control various parameters of
> the engine.
> End users could like to have some control over strength of the algorithm, etc.
>
> 3. If GTP would supports chats, KGS would probably implement it.
>
> 4. Opponent identification.
>
> 5. Interrupt. Users do not always want to wait until the program finish work.
> GoGui uses comment "#interrupt" to do it, but this is a hack.
> (this is somewhat related to 1.)
>
> 6. Position setup. I had conversation with Marcus about setup in GoGui.
> And we concluded that there should be a separate command for that.
>
> Would You like to have those issues solved?
> I hope we can get somewhere. :)
>
> Best Regards,
> Łukasz
> _______________________________________________
> computer-go mailing list
> [email protected]
> http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
