Proposal for GoServer Improvements
==================================


Here is the scenario I want to achieve:

	Ben goes to a red-bean web page, and using a Perl/CGI script,
	he launches a standalone GoServer on a particular port.

	Ben then goes to another red-bean web page which shows him a
	list of running GoServers (and who's playing each).  He
	selects his newly launched server from the list, and poof, up
	comes the GoGame client application, right within his browser.

	Ben makes the first move.  Then he quits Netscape altogether.

	Later that day, Karl points his browser at red-bean, and sees
	that Ben has started a game.  Karl brings up a new GoGame
	client, connects to the still-running server, and places a
	stone in response to Ben's.

	Karl logs off, and the game goes on for many days this way.

        // Wow, you're so right, detachability is a must!  I totally
        // hadn't thought of that.


Here are the architectural requirements for this scenario:


     * Tenet 1:  The server must keep a GoBoard object internally.

     Obviously, since the server is the only thing that keeps the game
     alive between client login sessions, it must hold on to the
     GoBoard.  However, I *don't* want to put any real intelligence
     into the server.  Karl and I decided a long time ago that it's
     just a Good Thing to put all intelligence in the clients.

     Therefore, the *wrong* way to do this is have the server actually
     try to comprehend every stone-placement message that passes
     through and update its own GoBoard;  the *right* way to do this
     is much simpler:  use the "Save" command in the menu.  In other
     words, after a player places a stone and wants to log off, he
     first runs "File-->Save" (or perhaps the games asks him if he
     wants to save before quitting), at which point the game is saved
     to disk (if the client is a full applications) AND ALSO the
     player's GoBoard is stored *back* within the server!  Simple!
     Elegant!

     // Mmm, er, uh... couldn't disagree more?
     //
     // Depending on people to remember to save (even if reminded) is
     // a losing proposition.  Remember, we've decided that all
     // communications about the state of the board will take place in
     // either bkgo protocol or SGF transfers (which are really a
     // subset of bkgo protocol).  Personally, I don't think it's so
     // bad for the server to know & understand the state of the board
     // -- after all, we've already written the classes and the logic
     // for that, so why not use 'em?  Then the server can be running
     // in a mode where it saves to SGF after every move... and if it
     // accidentally dies and has to start up again, it knows to look
     // for a certain SGF file.
     // 
     // We shouldn't ever be storing anything in raw GoBoard format,
     // nor should we store the same thing in two different places
     // (server and client).  We should decide that the server is the
     // place, and SGF is the format, and that way we never have to
     // worry about local and remote records disagreeing with each
     // other, or what happens when someone upgrades their server
     // while games are in progress and suddenly can't read the raw
     // GoBoards, etc.  Keep it simple, keep it on the server.
     //
     // Just as a general UI principle, too: it's never the Right
     // Way to add an operation that the user must perform manually
     // when we know they'll need to do it every time.  If the user
     // would have to save after every move, then insisting that they
     // actually go to the save menu and _do_ it is a Bad Thing.  It
     // should be automated.
     //
     // (Now, we will need a way to download the SGF record from the
     // server to the clients, like a web page offering "Download SGF"
     // or something...)
     //
     // Thoughts?      -karl

--------------
Ben's Response:

	Well, no, you're not really disagreeing about everything here.

	First, I *do* agree that each player shouldn't have to
	remember to save the game on the server before quitting.  I've
	already started to fix that;  when quitting, GoGame will
	automatically send its board to the server, whether it be an
	applet or an application.  

	But do you realize the enormous complexity of what you're
	advocating?  It is *not* trivial at all to make the server
	understand each stone-placement message that passes through.
	It could get really, really ugly.

	So my question is:  why do you think it's worth the effort?
	Why not let the clients do the intelligent board-state
	keeping, as they do now, and just allow the clients to store
	their state on the server?  I mean, why fix what ain't broke?



------------------

     * Tenet 2:  Authentication is needed.

     Who has the right to modify a game in progress?

     If Ben and Karl are playing a extended game of Go over many
     weeks, what is to stop some malicious person from:

     a) connecting as black or white and placing stones?
     b) loading up a whole blank new board, or some random saved game?
     c) telling the CGI scripts to kill the whole server process?

     The answer is simple:  we need authentication.

     Right now, the server keeps a transient, temporary list of
     players who happen to be connected at *the moment*.  But it needs
     to have a permanent list of people who have The Right to place a
     stone or modify the board in any way.

     Again, this is very simple:  we simply add a new field to the
     GoPlayer class -- a password field.  When a player *first*
     connects as a black or white player, they can set a password for
     themselves.  These two passwords are kept permanently within the
     server for future authentication.  Then, anytime someone wants to
     do any of a), b), or c) above, the server will require the
     password.

     // Amen, nice plan.  Shouldn't be prompted until try to make a
     // move, of course.   -karl