Re: [XBoard-devel] Polyglot 2.0,

[h.g. muller]

Note that at the time this thread was started, the issue was more than
only cosmetic: The crucial patch I put in made to 1.4.38b to create
"Polyglot 2.0.38b" is the one that allows it to save the current settings
back to the polyglot.ini file. It is this functonality that Polyglot 1.4.38b
did not have, but which is crucial to the usefulness of the new WinBoard
Engine-Settings dialog. If all pain-staking adjustment people make for
tuning the engine would get lost after re-starting WinBoard, it might as
well not have been there.

Naturaly, when I was making a new version, I also patched some minor
issues. Some of them were cosmetic (e.g. the order of the Polyglot options,
to give a nicer layout in the engine-settings dialog), but it also included
removal of options who's presence should be considered bugs because
they are duplicates of things handled by other WB protocol commands
(Chess960), and options that I consider undesirable in WB engines
(kibitz, nice). I also put in a dummy option to show the version number,
so people could easily recognize it as a fork. If I am starting a fork,
which the save option necessitated, I might as well try to perfect it.

About the design philosophy: Polyglot is  protocol adapter. The tast
of an adapter is to make engines using protocol B (in this case UCI)
appear as if they are native protocol A engines (in this case WB).
That means the GUI must be blind to the fact that an adapter is used.
If it would have to take special actions when running an engine through
the adapter that it would not have to take when running a native engine,
the adapter would not fully do its job. As far as WinBoard is concerned
Polyglot _is_ the engine, and I think it would be bad design if WinBoard
would have to treat Polyglot options differently than engine options
(for reasons other than that there are many using the same prefix,
which WinBoard considers a valid reason for gouping options).

There might be other protocols than UCI, and other adapters that
Polyglot (or other Polyglot versions) for UCI, and if we would have to
make special provisions in the GUI to create work-arounds for the
imperfections of each of them, things would become very messy.
Polyglot must behave and be treated like it is a native WB engine.
If it sends a feature option="..." to WinBoard, that option must appear
in the dialog, because that is what the protocol specs say.

As to the issue of "undesirable" options: some native WB engines
are non-compliant with WB protocol specs. E.g. they do not send
thinking output even though they received a "post" command,
show scores with the wrong sign, etc. Now this is bad enough,
but unfortunately cannot be helped. But I think it is a bad idea to
provide a protocol adapter with options that serve no other purpose
than to make the engine non-compliant, and an even worse idea
to invite the user to use these options by presenting them in an
interactive dialog. Note that WB protocol specifies nowhere that
it is n obligation of the engine to send every adjustable parameter
it has as an option feature. This should be purely reserved for
options that should be set interactively and frequently. But it is
the decision of the engine author what to include; the GUI should
respect it.

Since Polyglot will be front-end for so many engines, I would
like it to behave as a model example of how native WB engines
should do things. So I think it is a bad idea to provide a Polyglot
that invites people to equip UCI engines which in itself were decently
behaving engines with options that I would strongly recommend
against in native WinBoard engines. Such as engines adjusting
their own "nice" value, or non-compliant ways to kibitz.

But all that is of lesser importance, and could even be described
as perfectionism. The main issue was the ability to save the options.
Next to that, the only thing I strongly disliked about Polyglot 1.4.38b
are the WbWorkAround options. They serve no purpose, as they
provide work-arounds for problems that only WinBoard versions have
that cannot process the options anyway. And one of them has the
wrong default value. (Work-arounds should be switched off by default,
not on.)