> Ok. I was always under the impression that the aim was to create
some generic mechanism by which the user
> would be unaware that PG is being used internally to handle UCI
engines. Apparently
> this was a communication problem.
Well, this is a good goal, but I just don't see how you could do it in
this case.
The fact that two versions of the same engine can co-exist is only
because
Polyglot allows it. With native WinBoard engines this would not be
possible.
The user would either have to install it under a different name of the
executable,
or in a different folder.
I guess UCI engines could mimic that by using the -fd argument in the
path
of the settings file. But it is an ugly kludge in the first place, so I
am not sure
it is worth mimicking. To make it possible in the scheme where Polyglot
would
derive the ini-file name from what the engine reports, it would need a
new argument
SettingsPath to make that possible. The default for this would then be
_PG,
but WB could use the adapterCommand
polyglot -ec %<fcp> -ed %<fd> -sp %<fd>
meaning that the settings files will always be stored with the
engine.