Just one thought. Use fastcgi instead of cgi. The difference between cgi and fastcgi is that you have your 'code' running all the time. Not loaded at every web access. This makes it possible to keep GNU Go running and talk GTP with GNU Go. The problem with this solution is, if you run GNU Go for every new game. How do you know when to stop GNU Go. End of game and time out is to ways. But you do not want lots of GNU Go to run as zombies. And another problem can be all web servers does not support this.
Also, web servers often have there own API that can give the same functions as fastcgi. And actually on some web servers fastcgi module is made with these APIs. * http://www.fastcgi.com/ Jens > On 11/29/06, Arvid Piehl Lauritsen Böttiger <[EMAIL PROTECTED]> wrote: > >> I guess my main-problem is how I can make gnugo remember a state? [...] >> Second - is there a good way to feed gnugo a state? > > Alain already pointed you to the jeudego frontend, which was based on > a CGI I wrote awhile ago. I used command line parameters to talk to > GNU Go, and avoided serverside persistence by saving the game state as > SGF in a hidden variable in the form -- more of a Web 0.9 approach > than what you're contemplating. If you're interested in looking at the > code, it was included with GNU Go 3.4 under interface/html, but it > broke at some point and eventually got deleted. > > doug. > > > _______________________________________________ > gnugo-devel mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/gnugo-devel _______________________________________________ gnugo-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnugo-devel
