WinBoard and TLCS

[H.G.Muller]

I have been thinking a bit about the relationship between WinBoard and TLCS. The fact that TLCS works from the debug file is in fact a 'historic accident', because at the time it was the only way to get real-time game info and engine PVs. But technically, it has always been a poor solution, that you would not choose if you were designing a broadcasting system from scratch. So I wonder if it would be wise to let it affect WinBoard design, by doing things in the built-in tournament manager in an unnatural way, just to keep an existing work-around-type solution alive.

In principle all that broadcasters need to do their job is the communication with the engines. And in fact I guess even part of this is irrelevant (e.g. most of the feature handshaking). I could make WinBoard write that info on a separate file ('broadcast file'), sort of a lean version of the debug file.

That would not burdon WinBoard's handling of the real debug file with unnatural constraints. I could just let WinBoard open the broadcast file every time a new game starts, (i.e. just before the new command was sent), and write some info in it so the broadcaster can determine who is playing. (e.f. fake feature myname="..." commands from the engine that in reality might not have been sent at all, because the engine was already loaded on a previous game, or because it is a v1 engine.) After that, all traffic to and from the engines would be dumped on that broadcast file (as well as on the debug file when debug is on). And the file would be closed when the game ends, possibly after apending a recognizable message that says so. (Although the broadcaster could see it from the result commands sent to the engines.)

The next game would then open the file again for overwriting, rather than appending. This would also work when the file in fact was a pre-existing "named pipe" set up by the broadcaster, which seems the technologically best solution for this problem.