On Tue, 2008-02-26 at 12:28 -0500, Don Dailey wrote: > Regarding use GTP for the CGOS communication protocol: > > At one point I actually seriously considered using GTP as the > communication protocol for CGOS. It seemed rather cool that it might > be possible to hook up a program directly without needing a separate > client. It seems like we may have even discussed it on this group. I > did discuss this with the gogui people I believe.
I found at least one discussion from the early CGOS days. It was part of a larger thread that had nothing to do with CGOS so I'll link to Don's post and you can click the [thread] view from there to see the follow-ups: http://computer-go.org/pipermail/computer-go/2006-March/004903.html It discusses the authentication issues, the socket issues, and nice ideas like being able to re-use GoGui with different servers, like the Random Go Challenge mentioned by Markus: http://www.lysator.liu.se/~gunnar/gtp/random_go_challenge.html One quote from you (Don) stands out: "I know this is one of those things I would regret later - not sticking to just 1 way to communicate. Even when it seems like it wouldn't be a big deal - I always kick myself for not following my instinct." I think you should be kicking yourself for not going with GTP all the way through :) > A couple of issues made me change my mind. One of them is exactly what > Álvaro mentions, the authentication issue. There is nothing in the > GTP protocol to cover this and it seemed to be outside the scope of the > protocol. You could separate authentication and consider it just a > separate step in the process, but this is certainly no simplification. It seems to me adding two GTP commands for login and password is extremely simple, and could always be replaced later by ssh or kerberos or whatever, should the need arise. > The other issue is that GTP is normally done over pipes, not sockets. > It doesn't really matter how you send and receive the messages of > course, but it certainly doesn't make most programs immediately > usable. It's easy enough in unix based systems using unix tools but at > this point you already using an external program anyway. But they are standard tools and you don't need to install ad-hoc clients for every server that somebody dreams up. The Random Go Challenge page shows how simple it is to convert from a TCP stream to a GTP standard input stream with tcpconnect. > A third issue is that I wanted the flexibility to add things not covered > by GTP, such as informational messages. I did not want to require > people to constantly be modifying their GTP implementations to > accommodate CGOS. GTP messages that aren't understood can be ignored. As long as the server only requires the basics from a GTP engine (boardsize, genmove, etc), with everything else optional, I don't see what the problem is. > A fourth issue is that wanted to minimize the number of messages passing > back and forth. So the CGOS protocol is less verbose in that sense. > If I stayed with strict GTP I would be sending a more tiny message back > and forth. How much are you saving? The vast majority of commands are genmove w/b followed by a response. That and there's only a handful of people connecting anyways. This sounds like pre-mature optimization. > Every few months, I get a private email asking why I didn't use GTP. I > think this is the first one sent to the computer-go list. Each time > the person believes he is the first to think of the idea. This is overly harsh. There's a difference between asking a "why isn't this done this way" Frequently Asked Question and believing that you're the first to ask the question. Anyways, I'm glad it was brought up again. I'd like to see a move to GTP for the server -- it's almost GTP anyways. You did say in that old thread I linked to: "But if enough people express interest I may very well do this - it's a trivial modification to the server." It seems that there is interest. -Jeff _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
