[XBoard-devel] Protocol development (old v3 draft)

[h.g. muller]

I have looked at the old protocol v3 draft, drawn up by Tim and Daniel,
as well as through some of the dicusions on this and other matters
in Tim's chess-todo e-mail archive. Below a list as to what I think
we should do with it:
_________________________________________________________________

                               PROTOCOL v3 DRAFT

RESET
We can define that in the protocol; there is no application for it in 
XBoard anyway,
so there is nothing to implement.

MULTI PV
We can define this, and it is quite easy to implement. I would not have the
engine report in the feature command how many lines it can maximally support.
If it cannot meet the demand, it should just give what it can.
Apart from recognizing the feature command, little to no support is needed.
Perhaps some automatic sorting of the lines in the Engine-Output window,
so that the score-wise best line always is the top-most one.
This is simply a matter of inserting the new line not always at the top,
but somewhat lower down if it has a lower score. (But amongst lines of same 
depth.)
Worst thing (as always) would be to provide the user interface to switch it on.

MULTI-SESSION TC
I would extend the definition of the multi-session level command to the case
where it occurs during the game, and actually use that in the XBoard 
implementation.
The clock management for multi-session is already implemented in XBoard 
4.4, btw.
Just the protocol to inform the engine is lacking.
The biggest job here is to offer work-arounds for engines that do not 
officially
support it, to coaxed them into playing multi-session anyway.

THINKING OUTPUT
I think the proposed v3 format extension is bad, and I have a counter proposal.
The stat01 lines I don't want to extend at all, but rather deprecate 
altogether,
as the new format for Thinking Output should take over their role.
The proposal includes standardization of mate scores and score sign convention.

# MESSAGE
Already implemented, but under control of a feature (so the engine can probe
if it the GUI supports this, rather than deduce it from the protocol 
version nr).

MARTIN'S SUGGESTIONS
We can add  'author' and 'country'  string features, similar to the 'myname'
feature, but I would not implement them in XBoard. (But Arena might like 
them.)
His other suggestions duplicate existing features or are too specialized
(and thus better implemented through the existing option-feature mechanism).

RESTRICTIONS
I think it is bad to require that some commands only are allowed in force mode,
or when the engine is not thinking or pondering. This would make engines
supporting v3 not automatically support v2. I think we should drop that idea.

                         SOME OTHER DISCUSSED EXTENSIONS

BOOK ENGINES
Desirability questionable, now XBoard supports a GUI book.
The 'parallel' design seems in practice to have lost to the 'serial' design,
book adapters are quite common now, even commercially. In a parallel design
it is not clear anyway if the direct communication between GUI and book engine
should count as WB protocol.

MATE SCORES
Not desirable to have the engine define its own standard through a feature.
A new global standard is defined with the extended Thinking-Output format,
and engines should simply translate their output to that, rather than
tell the GUI how to translate their output to the standard.

ENGINE-SPECIFIC COMMANDS
Already implemented through the option feature.

ATOMIC DRAW-CLAIMS
Satisfactorily solved in existing protocol through the offer-draw kludge.

BUGHOUSE SUPPORT
Hard, and requires some design effort. It seems to me that in local mode
an engine should not only be able to be informed on the progress in two
games, but actually play these two games as well. How about prefixing
all WB commands in either direction by 1st_ or 2nd_ depending on if they
apply to game 1 or game 2? (So you could independently put either game
in force mode.)