Single Comment

Fergus:
| That is wrong. A player views a board in his web browser, enters a move
| in a form, then submits the form. Game Courier then displays the move 
| or tells the player that the move is illegal. If the move is not found 
| illegal (either because it is not or because the preset doesn't enforce
| rules), the player then clicks a form button to verify that this was 
| his intended move. The player can find out when it is his move again in
| one of three ways: (1) Get an email, (2) check the logs page, or (3) 
| let the Game Courier page reload at intervals (by means of Javascript) 
| until it is his move again.

Well, it is not that wrong: the latter is what I mean by polling, you
either have to poll your POP server to see if you have mail, or keep
requesting the page over the http port. The latter you could do by hand,
by clicking the browser refresh button, or have the browser programmed to
do it by JavaScript. Or have an independent program that you wrote
yourself (not a browser) do it.

This is different from the way the normal ICS protocol works, where the
TCP link to the server is two-way, and the server actively sends a signal
to the client when the opponent moved. Especially in bullet games you
would have to poll so frequently to get decent response times that it
would likely overload the server.

As to submitting a form: doesn't the browser simply open a TCP link to
port 80 of the server for that, and send it an http packet with arguments
appended to a file name (after a question mark, or something like that),
which the PHP server can interpret?

If I would know what text messages are interchanged over the various TCP
links that the browser opens to the server (and which ports it uses to
establish these links), it is easy enough to write a backend for WinBoard
that generates and interprets these messages. 

If I would know how to use Game Courier, I would simply use a packet
sniffer like WireShark to record what went over the line when I was doing
it; this is how I did it for the Unspeakable-variant server. But there I
knew how to operate the client to play on the server (which in that case
was a Java program, that was downloaded by the browser). But I had the
disadvantage that I was not able to pump the programmer for information.
;-)

Is the form that you send to enter the move variant dependent, or always
the same? I suppose the move syntax itself could be variant dependent. Or
is it simply long algebraic notation? How do you learn what the
opponent's move is. Do you get sent a new board position, and do you have
to decode the move from that by differencing it against the previous
position? Or is the move itself somewhere on the page, and if so, in which
format?