A couple of xboard 4.3.15 bugs(?)

[hgm]

In the case I showed I logged in by hand, so that is always slow. But if login is automatic I can very well imagine it beats initialization of the engine, and then there would not be any problem.

[sje]

I have done some more work on this item and I've confirmed that an immediate "tellics" after the "xboard" command does NOT make it to the server.

However, if the "tellics" is delayed until the first "go" or "usermove" of a game, then it DOES make it to the server.

Probably the best fix is for xboard to wait until the ICS login is complete before sending the "xboard" command to an engine. An alternative is for xboard to queue the engine responses before a login is complete and then process them in order.

[hgm]

I am not sure. The best fix might be to state in the protocol specs that you cannot do this. It seems contrary to the design philosophy according to which XBoard is built. It is not the task of the engine to set up the ICS for the session; this is meant to be done in the -icslogon file. If you don't -reuse the engine, what the engine tells in response to xboard would be repeated every game, so you might as well sent it after go if you really want this to come from the engine.

[sje]

I am not sure. The best fix might be to state in the protocol specs that you cannot do this. It seems contrary to the design philosophy according to which XBoard is built. It is not the task of the engine to set up the ICS for the session; this is meant to be done in the -icslogon file. If you don't -reuse the engine, what the engine tells in response to xboard would be repeated every game, so you might as well sent it after go if you really want this to come from the engine.

The problem with using the icslogon file is that the file is not part of the engine, and only the engine knows for sure what its name and version are. The version could change every day, or even more frequently.

"The man with one wristwatch knows what time it is; the man with two watches is never sure."