Re: [computer-go] Wishlist for playing programs on KGS

["William M. Shubert" <wms@xxxxxxxxxx>]

After thinking it over, I have decided that maybe the best solution is
one that would give the most flexibility to the engine authors, at the
expense of some complexity to them. This solution I'm about to propose
is something that has been requested before for other reasons, and it
may be useful in general.

My solution:
     1. Whenever a user talks to the engine at all, forward the text as
        a KGS-specific command. Something like "kgs-chat <username>
        <text>"
     2. If the response to this command to the engine is a success and
        includes text after the "=", then the text of the response will
        be sent back to the user who sent the chat.
     3. When a game ends, the engine will get a clear board request.
        Since clear boards never appear in-game (as long as you support
        the undo command that is!), an engine can treat this command as
        a "the game is over" signal. When the engine exits, kgsGtp logs
        out, so if an engine decides though chat or any other mechanism
        that it should log out when the game ends, it can simply exit
        when it gets the next clear board request (or exit right now if
        the last request that it received was a clear board).
     4. This does have the drawback that, like all GTP commands, it will
        be serialized, so if you send a message to the engine while it
        is thinking, you will not get a response until the reponse move
        arrives.

Obviously in addition to using this mechanism to shut the engine down at
the end of the game, it can be used as a general query of engine state
if the engine programmer wishes. kgsGtp will simply pass through all
chats from all users, the engine author can do as much or as little as
they wish with these.

My feelings on the other proposals:
      * Rereading the configuration added a lot of complexity and
        confusing issues. Some things couldn't be changed after login
        (e.g., user name of the engine), others could, and dividing the
        properties up into these groups is difficult. There is also the
        race condition, what if the file is read while it is being
        written, and I get a partial file? Could lead to weird bugs.
        Overall seems very "hack-like".
      * Having magic messages that the GTP client itself understands,
        without forwarding to the engine, simplifies things but removes
        a lot of flexibility.
      * Adding an extra GTP command to query the engine "should we do
        another game?" also lacks flexibility, and doesn't seem to
        simplify engine programming any over the chatting proposal.
        Really instead of this, the engine could simply exit when it
        gets a request to clear the board, that would do about the same
        thing.

Comments are welcome. If the consensus is that this will be useful, then
I'll add it to my to-do list.

_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/