OK, I uploaded something that seems to work, to
http://hgm.nubati.net/broadcast.exe
This program can be used to push games to a viewer web page on an external server in real time, by placing it in the WinBoard folder, and specifying it as debug file for WinBoard through the following additional options:
-debug -debugfile "///broadcast PASSWORD msca1 SERVER_URL"
The SERVER_URL is optional, and would default to hgm.nubati.net. With the correct PASSWORD, this will cause the games played by WinBoard to appear then at
http://hgm.nubati.net/variants/msca1/
(There are already some 30 games there, mostly crap, which I created during debugging. I will throw all test games away just before the real tournament starts.)
The way it works is that WinBoard pipes its debug output to broadcast.exe (which it launches, triggered by the '///' prefix in the name of the debug file). Broadcast.exe extracts the moves to and from the first engine, and the thinking output of both engines from this, and buffers those in an internal pipe, until one of the engines is set thinking by a go command (or a move directly after 'new'). Only at that time it can know which engine plays which color, and it will create a game on the server by accessing http://SERVER_URL/cgi-bin/tbserver.cgi with the proper parameters.
Then a separate sender thread gets unblocked, and starts reading moves from the internal pipe to deposit them to the server through the same CGI script (but with different parameters). A 'result' command to the first engine, indicating the end of the game, also goes through the internal pipe, and causes the sender thread to revert to the blocked state.
The moves are deposited together with a comment, currently consisting of score/depth. The viewer page now displays this comment a few lines above the board. I will change that page to display it as replacement for the red message. This is purely a server matter; the HTML page and its associated JavaScript determine how the deposited game moves are interpreted.
There are several things I am not happy about, which I will fix the next few days:
* The game result is not properly deposited yet. In human games for which the server was designed the only ways to terminate a game is by resigning or mutual agreement to a draw. When WinBoard is uploading the game, however, it can also terminate with the winning side on move, and it should also be possible to specify a draw without a previous offer. This will require some additions to tbserver.cgi to accept commands for this, and then in broadcast.exe to send these commands.
* I am very unhappy that the broadcast.exe is variant-dependent. This is caused by the need to convert SAN drop moves to the format used by the JavaScript associated with the viewer. The JavaScript needs the pieces by number (according to their position in the piece-legend table), while SAN indicates them by ID. So broadcast.exe has to translate the letters into numbers, a task that depends on the table layout on the viewer page for which it is working.
* It would be nice to have clocks on the viewer page, which count down by themselves, and are synchronized whenever moves come in.
* When the viewer page displays an unfinished game, it should automatically poll the server, waiting for new moves.
