How to post chess games

[Rebel]

I noticed see: http://www.top-5000.nl/pgn4web/live.htm

Nice job!

Besides "SetPgnUrl" is there also a sort of "SetPgnPath" option that points to a place on the harddisk?

Say, SetPgnPath ("c:\game.pgn");

As I have it currently the PGN must be uploaded to the server every time?

I couldn't find such an option in the README.

[pgn4web]

I noticed see: http://www.top-5000.nl/pgn4web/live.htm

Nice job!

Besides "SetPgnUrl" is there also a sort of "SetPgnPath" option that points to a place on the harddisk?

Say, SetPgnPath ("c:\game.pgn");

As I have it currently the PGN must be uploaded to the server every time?

I couldn't find such an option in the README.

If you think about it, if my web browser on MY laptop reads the instruction SetPgnPath ("c:\game.pgn"), how is it supposed to know this is a file on YOUR laptop?

pgn4web needs the URL for the client's browser to get the PGN from your server. My web browser really can not access files on your laptop, unless that file is made available from a URL. The parameter of SetPgnUrl can point to a different folder, such as SetPgnUrl("/here/there/somewhere/file.pgn"), but the PGN file URL *must* be on the same web domain as the javascript file (it's a javascript restriction).

The PGN must be uploaded to the server every time, but it's straightforward to run a script every few seconds for doing that as a last resort.

Also note, even for your own personal use from your laptop, many web browsers have issues with opening the pgn4web pages from a folder in your laptop; you really need to always use a web server; pgn4web has been designed for use through a web server, even testing opening files from a local folder might not work.

PS: also noticed that your live page (and the database page as well) copied a template where you set the CSS for the piece images at 36x36 dimensions but then you load the "alpha/24" bitmaps. Most browsers cope with that, but you'll get a crispier look if you replace SetImagePath("alpha/24") with SetImagePath("alpha/36"). You'd also need to add the alpha/36 folder to your server, it seems missing at the moment.

[pgn4web]

I noticed see: http://www.top-5000.nl/pgn4web/live.htm

Also, for live games you should really use SetInitialHalfmove("end", true), when opening a live game people really want to see the live position (the end of the PGN file)...

[Rebel]

I noticed see: http://www.top-5000.nl/pgn4web/live.htm

Nice job!

Besides "SetPgnUrl" is there also a sort of "SetPgnPath" option that points to a place on the harddisk?

Say, SetPgnPath ("c:\game.pgn");

As I have it currently the PGN must be uploaded to the server every time?

I couldn't find such an option in the README.

If you think about it, if my web browser on MY laptop reads the instruction SetPgnPath ("c:\game.pgn"), how is it supposed to know this is a file on YOUR laptop?

TLCV does.

Code: Select all

TOURNEYPGN=C:\arena\all.pgn

pgn4web needs the URL for the client's browser to get the PGN from your server. My web browser really can not access files on your laptop, unless that file is made available from a URL. The parameter of SetPgnUrl can point to a different folder, such as SetPgnUrl("/here/there/somewhere/file.pgn"), but the PGN file URL *must* be on the same web domain as the javascript file (it's a javascript restriction).

Ok, I understand.

The PGN must be uploaded to the server every time, but it's straightforward to run a script every few seconds for doing that as a last resort.

I will look for such an utlity then.

Also note, even for your own personal use from your laptop, many web browsers have issues with opening the pgn4web pages from a folder in your laptop; you really need to always use a web server; pgn4web has been designed for use through a web server, even testing opening files from a local folder might not work.

PS: also noticed that your live page (and the database page as well) copied a template where you set the CSS for the piece images at 36x36 dimensions but then you load the "alpha/24" bitmaps. Most browsers cope with that, but you'll get a crispier look if you replace SetImagePath("alpha/24") with SetImagePath("alpha/36"). You'd also need to add the alpha/36 folder to your server, it seems missing at the moment.

Thank you for the help.

[pgn4web]

TLCV does.

Code: Select all

TOURNEYPGN=C:\arena\all.pgn

It's a different approach to the problem. pgn4web runs exclusively between the web client and the web server as standard HTML5 content. I do not know much about TLCV, but I guess it requires a dedicated/custom application running on your server that takes care of taking the PGN file from wherever it is and make it available where it needs to be.

It should not be difficult to run a simple batch script that uploads the PGN file at regular intervals using ftp or something like it.

[H.G.Muller]

When I was broadcasting live tournaments through a JavaScript viewer I just configured the machine where the games were running as a web server. (I used the free Abyss web-server for Windows for that.) Then the viewer (for which the HTML and JS files were also on the machine) could directly access the game files. It was a bit of an annoyance that I could not put the viewer page itself on my regular web server, and have it sneakily retrieve the game file it needed from the machine where the game was running. But, like pgn4web says, JavaScript forbids this (for security reasons).

TLCV is complex. The original version is not browser-based, so you have to download a dedicated client. On the server side TLCS must run on the machine where you play the games, and it makes that machine a dedicated server for TLCV clients only. But once they connect it reverses the client-server relationship, and initiates connections to all logged-in clients whenever the game produced new data (moves or PVs). So users of TLCV have to rig their computer as a server, opening holes in all firewalls (including their modems and routers). Which is such a pain that many people never get it running.

There are several aspects of my old broadcasting system I consider unsatisfactory, and I am trying to find better solutions for. For independent reasons I developed a turn-based server as a CGI script, for which the JavaScript client also contains a viewer function (e.g. http://hgm.nubati.net/variants/elven ), and where the normal web interface can deposit moves for adding to the game (using a HTML GET method). This can potentially be used for broadcasting, by letting the broadcasting entity deposit moves for both sides. I am thinking about equiping the turn-based server with real-time capability anyway, through 'long polling' (meaning that the CGI server script will not deny a request for a not-yet-existing move, but will wait for that move to be deposited and then satisfy the client request after all). That way the clients would be immediately informed of any deposited move.

I already built an undocumented feature into WinBoard to assist in depositing moves: rather then writing the debug information (containing all engine-GUI communication) on a file, you can also send it to another process through a pipe. At the other end of the pipe a broadcaster program could be waiting for input with an ordinary blocking read, and as soon as it arrives, pick out the stuff it wants to broadcast (e.g. the moves and the not-too-early PVs, and perhaps clock times), and immediately deposit it to a remote server through an URL request to the CGI script. I already made a trial version of such a broadcaster.

[pgn4web]

When I was broadcasting live tournaments through a JavaScript viewer I just configured the machine where the games were running as a web server.

This is all good for a small scale application, but I understand why you moved on for a more serious application with a real audience. Separating the machine running the games and the machine for web presentation just makes sense. This is how TCEC is run, with nothing else on that machine other than the engines playing, cutechess as tournament manager and generating the PGN and a small batch script to FTP the PGN to the web server.

Ideally, in my view, the function of the batch script belongs to the tool generating the PGN, the optimal solution in the TCEC case would be for cutechess to incorporate the ftp client and to be able to upload the file when a new PGN is generated; besides the additional complexity, the current external script has the drawback that a small delay might be added unnecessarily form the availability of the PGN on the local file till the availability of the PGN on the web server for everyone to use. In this respect I'm happy to see you are introducing more flexibility into winboard to facilitate the generation of a custom PGN file and the timely upload on a different server.

[H.G.Muller]

Well, for WinBoard I prefer the modular approach, locating the code that does the actual upload in a comparatively simple external module. Then people can easily adapt what exactly is uploaded to their needs by changing that program. Not everyone might want to broadcast the same information.

E.g. the broadcaster could simply deposit moves, by accessing the URL

Code: Select all

http://hgm.nubati.net/cgi-bin/tbserver.cgi?directory=games&file=327&password=abracadabra&append=2.Nf3

upon receiving the info that the engine played 2.Nf3 from the GUI. The tbserver.cgi script would simply verify the password (so that others cannot vandalize the broadcast by submitting their own stuff), and if it is OK it would append the specified text (in this case 2.Nf3, but it could have been an arbitrary text) to a file /games/327 on the server. No need for ftp. The JavaScript client would just access that file. Or better yet, it could ask the tbserver.cgi script to send it part of that file by something like

Code: Select all

http://hgm.nubati.net/cgi-bin/tbserver.cgi?directory=games&file=327&retrieve=239

(no password required) which would skip the first 239 characters (which the viewer would already have, say), and if there was nothing beyound that yet it would wait until something is appended to the file, and then send that to the client. Then you would not have to download the entire game file all the time. The tbserver.cgi can be pretty dumb, with just 'append', 'replace' and 'retrieve' functions. 'replace' would be useful to maintain a file on the server with the latest thinking output of the engine, so that the viewers can follow the engine's thinking in real time. Such a server script can basically be used to broadcast anything, its only task is to add deposited info to some file, and allow clients to selectively request information from the end of a file. You could even use it for a chat server, by dedicating a file to the chat and allow users to deposit message there which the others retrieve.

[pgn4web]

E.g. the broadcaster could simply deposit moves, by accessing the URL

Code: Select all

http://hgm.nubati.net/cgi-bin/tbserver.cgi?directory=games&file=327&password=abracadabra&append=2.Nf3

The only issue I see with this approach is to require a custom script to run on the web server. This might or might not be an issue, depending on how much control you have on the web server setup. I have seen a few example of people broadcasting chess event with a very low cost budget that might not be able to deploy custom scripts and debug them as required. Relying on a standard tool like FTP makes the whole thing easier to setup, with all the custom software on the machine that generates the move (from chess engines, from live boards or any other source).

In general I tried to stay away as much as possible from defining proprietary interfaces and protocols: in order to display chess moves on a website the PGN format is far from optimal and there's infinite improvements that can be suggested for the communication to a web client. However, any of those proprietary suggestions might reduce the adoption of such a tool if the games have to be translated from PGN first.

[H.G.Muller]

I thought that things like CGI and PHP were absolutely standard in HTTP servers nowadays. It is clear that people who want to broadcast should have access to some server machine. It wouldn't be anymore difficult to upload a PHP or CGI file than to upload a PGN file. The idea is that the server-side script is completely universal, fit for any task. So there is no debugging, people just get it as part of the broadcasting package, and put it on the server machine, together with the HTML page where people are supposed to view the games.

The best place to convert the game to PGN seems the JavaScript client. Obviously any client that wants to deal with SAN moves will have to be knowledgeable about the game rules, as otherwise they would not be able to convert a downloaded PNG to a displayed Chess board. And if they know the rules, they can just as easily generate SAN from, say, coordinate notation, as it would be to decode the SAN to coordinates for updating the board.

But of course people that prefer it differently can also do the conversion to PGN in the broadcaster process. The tbserver.cgi script doesn't care, it just appends whatever you upload to the file. This is why I thought it was better to locate the broadcaster code in a separate module, rather than in the GUI; then people can replace it easily if they want to broadcast another format.