UCI protocol in winboard

[Engin]

hi,
why using for UCI engines all time the polyglot adapter?
why not implement the UCI protocol directly in winboard, and support both protocols WB and UCI ?

and winboard is the best ICS GUI to play engines on ICC and other servers.
i like to wish that winboard support 1:1 the UCI protocol too .

any other minds?

regards,
Engin

[Dann Corbit]

It's a good idea.

I think an even better idea is to combine both protocols into a single one.

Engines would understand any command from either command stream.

[H.G.Muller]

I think it would be a total waste of time to make WinBoard understand UCI. There would be no benefit to the user at all, he would not even notice it. The fact that WinBoard and Polyglot are running as two different processes is an implementation detail, invisible to the user.

[Dann Corbit]

I think it would be a total waste of time to make WinBoard understand UCI. There would be no benefit to the user at all, he would not even notice it. The fact that WinBoard and Polyglot are running as two different processes is an implementation detail, invisible to the user.

Imagine a new protocol called WBUCI.
It contains all the commands of both winboard protocol and UCI protocol.

A winboard engine will automatically work under it. (The engine responds to protover N, etc.)
A UCI engine will automatically work under it. (The engine responds to uci and ucinewgame, etc.)
An engine that uses WBUCI can run under Winboard protocol.
An engine that uses WBUCI can run under UCI protocol.
An engine that uses WBUCI natively can also run under WBUCI protocol, so that it can set options with the UCI protocol and it can understand single moves without sending the whole game list like Winboard.
It's the best of all possible worlds. I cannot imagine that anyone would not think it was a good idea.

UCI engines are far easier to configure. In this respect, even with improvements, the Winboard protocol lacks sadly.
The Winboard protocol is far better for game play and for learning, etc. In this respect, the UCI protocol lacks sadly.
A combined protocol is clearly better than either protocol.

[H.G.Muller]

I see little to no advantage in a WBUCI protocol. For one, no engines exist yet that would understand it, so from the viewpoint of the GUI it would initially amount to autodtection of the engine type (UCI or WB). When I sugested such autodetection for the purpoe of configring engines in a tournament manager, people strongly recommended against it, as with many existing engines this seems to cause trouble in GUIs that attempt it.

There is also no incentive for authors of new engines to use a mixed protocol (i.e. a subset of WBUCI that is not pure WB or pure UCI). On the contrary, doing so would be a guarantee that their engine will not run under most GUIs that only support pure WB or pure UCI. And there is absolutely nothing to be gained in terms of functionality. So why would they ever do it?

People that like a simple protocol where you can just send the most recent move, in stead of sending the entire game over and over again, can simply choose WinBoard protocol, and have the optiions of their engine set through WB protocol. They don't need to mix in UCI for that. I don't agree that all that WB protocol "lacks sadly" for configuring engines. In fact it is highly superior, and only when UCI3 will be commonly accepted as standard it can be said that UCI no longer lacks sadly compared to WB protocol for configuring engines.

[Olivier Deville]

I do like the idea the way Dann describes it. This could make Winboard even more popular.

Olivier

[H.G.Muller]

But you are not an engine author, so you will not write an engine using this WBUCI protocol. And I still don't see anyone else doing it either. Why intentionally write an engine in a way that would strongly limit the number of GUIs it can run under when you could do anything you want in a way that would make it run under most GUIs?

[Engin]

hi,
hmm... i don't understand really what you mean "it is a waste of time"?

maybe you want not to work on it ? because it is to difficult to implement on winboard?

i think this is a good idea that the main configaration of hash, egtb path, ponder ,threads must be on the winboard and not in the ini files for every engines.

that work of ini files makes more work then the GUI only send the uci command to the engine, and if this support hash,egtb, ponder,threads, then it can confugarate it self to send the engine all the main configaration in the GUI its have.

and that is less work for tournament managers that must be configurating the ini files and polyglot for some 200 uci engines

and it is not sure if its works with that polyglot and ini file ??

is it not possible to see how the polyglot source solved the uci commands and implement it directly in the winboard source too?

and the winboard can detect if an engine is winboard or uci, can simple send first "uci", if not responsed, then send "protover 2" for wb2 protocol, then if also not response, then simple send "xboard" for wb 1 protocol.

at least we must not using any adaptors, and not to much work on the ini files for every uci engines !.

regards,
Engin

[H.G.Muller]

By "waste of time" I mean that when someone wants to run a UCI engine under WinBoard today, he has to type the name of the engine, type /fUCI to indicate that it is UCI rather than WB, open the "Options -> Engine #1 Settings" menu in WinBoard, adapt the engine-specific settings, give them a name (e.g. "tornado.cfg") and tick "persistence" if he want any changes he made there to be permanent. He can then run the UCI engine flawlessly as often as he wants.

When someone would now do an enormous job of equiping WinBoard with a UCI interface, to run a UCI engine under this modified WinBoard, he has to type the name of the engine, type /fUCI to indicate that it is UCI rather than WB, open the "Options -> Engine #1 Settings" menu in WinBoard, adapt the engine-specific settings, give them a name (e.g. "tornado.cfg") and tick "persistence" if he want any changes he made there permanent. He can then run the UCI engine, probably unreliably and with lots of bugs, as the new code would not have had the years of debugging under field conditions that Polyglot has.

i think this is a good idea that the main configaration of hash, egtb path, ponder ,threads must be on the winboard and not in the ini files for every engines.
that work of ini files makes more work then the GUI only send the uci command to the engine, and if this support hash,egtb, ponder,threads, then it can confugarate it self to send the engine all the main configaration in the GUI its have.
and that is less work for tournament managers that must be configurating the ini files and polyglot for some 200 uci engines
and it is not sure if its works with that polyglot and ini file ??

This already works this way for about 5 years, ever since Winboard_x, in the menu that was called "Options -> UCI..." there. (And has been renamed by me to "Options -> Global Settings", as it now also applies to WinBoard engines.)

is it not possible to see how the polyglot source solved the uci commands and implement it directly in the winboard source too?

and the winboard can detect if an engine is winboard or uci, can simple send first "uci", if not responsed, then send "protover 2" for wb2 protocol, then if also not response, then simple send "xboard" for wb 1 protocol.

People warned me that such auto-detection does not work properly for many engines. Having the user tick a checkbox or type -fUCI is much more reliable, and does not seem too taxing. In any case, auto-detection is an issue that is completely separate from WinBoard supporting UCI directly. It can work both with and without Polyglot.

at least we must not using any adaptors, and not to much work on the ini files for every uci engines !.

regards,
Engin

[Engin]

you are mean on winboard 4.4 is this possible?
yes, i look it up on 4.4, but the GUI need the polyglot.exe to run UCI engines, it cant run without this.
maybe to create an ini or cfg file for polyglot is now easier with wb 4.4, but WB doesnt support the UCI protocol directly with the engine it self !
its support only WB2 and WB protocol only, for UCI engines that do polyglot translate to the WB protocol, there is little time lag between the adapter from GUI to engine and backward. Winboard can do this without any time lag directly to the engine and backward like WB protocol is doing allready. not ?

[H.G.Muller]

you are mean on winboard 4.4 is this possible?
yes, i look it up on 4.4, but the GUI need the polyglot.exe to run UCI engines, it cant run without this.

I did not say that WinBoard 4.4 could run UCI engines without using Polyglot. Just that to the user it would not make the slightest difference if it did. The user would have to do _exactly_ the same in terms of mouse clicks and keyboard strokes to run a UCI engine under WinBoard 4.4 which does use Polyglot as he would have to do when he was running under the hypothetical WinBoard_U which supports UCI directly. Absolutely nothing would have been gained.

maybe to create an ini or cfg file for polyglot is now easier with wb 4.4, but WB doesnt support the UCI protocol directly with the engine it self !
its support only WB2 and WB protocol only, for UCI engines that do polyglot translate to the WB protocol, there is little time lag between the adapter from GUI to engine and backward. Winboard can do this without any time lag directly to the engine and backward like WB protocol is doing allready. not ?

UCI always needs more processing because it requires a single move to be translated on an entire game. It doesn not really matter if this time is taken within WinBoard itself or in Polyglot. Furthermore, on modern PCs such processing times are totally negligible.

[Dann Corbit]

I see little to no advantage in a WBUCI protocol. For one, no engines exist yet that would understand it, so from the viewpoint of the GUI it would initially amount to autodtection of the engine type (UCI or WB). When I sugested such autodetection for the purpoe of configring engines in a tournament manager, people strongly recommended against it, as with many existing engines this seems to cause trouble in GUIs that attempt it.

There is also no incentive for authors of new engines to use a mixed protocol (i.e. a subset of WBUCI that is not pure WB or pure UCI). On the contrary, doing so would be a guarantee that their engine will not run under most GUIs that only support pure WB or pure UCI. And there is absolutely nothing to be gained in terms of functionality. So why would they ever do it?

People that like a simple protocol where you can just send the most recent move, in stead of sending the entire game over and over again, can simply choose WinBoard protocol, and have the optiions of their engine set through WB protocol. They don't need to mix in UCI for that. I don't agree that all that WB protocol "lacks sadly" for configuring engines. In fact it is highly superior, and only when UCI3 will be commonly accepted as standard it can be said that UCI no longer lacks sadly compared to WB protocol for configuring engines.

You don't understand what I mean.

This protocol works in three ways:
1. It is fully conginzant of Winboard, recognized Winboard protocols and communicates with Winboard engines using the Winboard protocol.
2. It is fully conginzant of UCI, recognized UCI protocols and communicates with UCI engines using the UCI protocol.
3. Is it's own protocol (WBUCI) which has the full advantages of both Winboard (which *clearly* does some things better than UCI) and has full advantages of UCI (which *clearly* does some things better than Winboard).

Eventually, all engines would become WBUCI engines, because this protocol is better than both alternatives.

[H.G.Muller]

Name one thing that UCI does do better than WB protocol.

Then we can fix that, which would be more productive. But I don't think will be anything to fix. Winboard options, for instance, are more versatile than UCI options. There are more different types, under which dynamic types such as -save and -reset, which can do things that UCI options cannot do. And they aren't so needlessly verbose as UCI options.

[Dann Corbit]

Name one thing that UCI does do better than WB protocol.

Then we can fix that, which would be more productive. But I don't think will be anything to fix. Winboard options, for instance, are more versatile than UCI options. There are more different types, under which dynamic types such as -save and -reset, which can do things that UCI options cannot do. And they aren't so needlessly verbose as UCI options.

UCI is far better at setting up engine parameters in a uniform way.

Winboard ini files are a hideous, bletcherous, treacherous nightmare.
It is unreasonable to expect any protocol to be able to parse 1000 different Winboard engine initialization files.
I know that you are adding extensions so that Winboard can recognize some parameters. Unfortunately, the Winboard engines themselves do not understand these options.

[Guenther Simon]

you are mean on winboard 4.4 is this possible?
yes, i look it up on 4.4, but the GUI need the polyglot.exe to run UCI engines, it cant run without this.
maybe to create an ini or cfg file for polyglot is now easier with wb 4.4, but WB doesnt support the UCI protocol directly with the engine it self !
its support only WB2 and WB protocol only, for UCI engines that do polyglot translate to the WB protocol, there is little time lag between the adapter from GUI to engine and backward. Winboard can do this without any time lag directly to the engine and backward like WB protocol is doing allready. not ?

May be there was a very very little time lag with older Polyglot versions, but even this very very little time lag still was much less,
than all time lag already produced by most of all other GUIs around, when simply running.
I don't see any need for UCI in Winboard and completely agree with HG on this.

Guenther

[H.G.Muller]

UCI is far better at setting up engine parameters in a uniform way.

Winboard ini files are a hideous, bletcherous, treacherous nightmare.
It is unreasonable to expect any protocol to be able to parse 1000 different Winboard engine initialization files.
I know that you are adding extensions so that Winboard can recognize some parameters. Unfortunately, the Winboard engines themselves do not understand these options.

I don't understand which ini files you are talking about, or what ini files have to do with WinBoard protocol. In my version of the protocol specs the word ini file does not appear.

I also don't see how making new protocol for which no engines exist is helping to solve the problem that not all engines make use existing protocol. It seems to me that making new protocol just makes that problem worse.

[Graham Banks]

In my humble opinion, the reason why the Winboard GUI isn't more popoular is because it's way too cumbersome and technical for many to bother with.
I'd quite happily give it a go if it was as easy to use as Arena and ChessGUI. Implementation of the UCI protocol would be a big step.

[H.G.Muller]

I believe this is already achieved with the latest WinBoard+Polyglot version (full install, including PSWBTM). I don't think direct implementation of the UCI protocol in WinBoard would contribute anything to this, as it would be totally unnoticeable by the user. Everything the user would have to do to install, configure and run engines would stay exactly the same as it is now.

If there is any criticism on the interface between user and PSWBTM/WinBoard, I would be happy to look how matters can be improved in that area. But things that are completely invisible to the user, like how exactly engine-GUI communication is implemented, in what language the GUI is written, if the engines use threads or processes, such technical details should be left to the respective implementers.

Note, however, that there is little I can do about the fact that some WinBoard engines are difficult to configure. E.g. through cryptic command-line options or cumbersome ini files. All I can do, and have done, is make sure that the means are availabe to engine authors to have their engine operate in a user-friendly manner, from the GUI dialog through the engine-GUI interface. If they choose to not use that and make their engine cumbersome, there is nothing I can do about that. But in that case configuring the engine would be equally cumbersome under other GUIs as well.

[Dann Corbit]

UCI is far better at setting up engine parameters in a uniform way.

Winboard ini files are a hideous, bletcherous, treacherous nightmare.
It is unreasonable to expect any protocol to be able to parse 1000 different Winboard engine initialization files.
I know that you are adding extensions so that Winboard can recognize some parameters. Unfortunately, the Winboard engines themselves do not understand these options.

I don't understand which ini files you are talking about, or what ini files have to do with WinBoard protocol. In my version of the protocol specs the word ini file does not appear.

I also don't see how making new protocol for which no engines exist is helping to solve the problem that not all engines make use existing protocol. It seems to me that making new protocol just makes that problem worse.

Winboard engines manage their parameters with INI files. Almost every engine has such a file. I have many thousands of engines (at least 5000) and at least 3000 of these are Winboard engines. Can you imagine trying to update 3000 ini files?

This is a problem with Winboard engines. They simply do not understand how to set their important settings through protocol use.
Some of the things you are doing are helpful to solve some of the difficulties. Consider the nalimov path setting. But it still won't help unless the engines know how to deal with it. How many Winboard engines can take a Nalimov path on the command line or from the environment? Answer: Very, very few. But nalimov paths are a single instance. There are many, many parameters possible and most Winboard engines require the setting of some parameters usually via an ini file. These ini files are not needed for UCI engines because UCI engines are fully settable from UCI options. UCI options are well designed and easy to use.

[H.G.Muller]

I understand all that, but how would you solve it by making yet more new protocol? You can make all the protocol you like, and you can even supply GUIs that implement it. And when you have done all that, _none_ of the problems you describe will have gone away. Every engine that was using INI files will still be using INI files. Engines that do not take the Nalimov path through the WB interface will not magically turn into engines that do because you offer more synonyms of the command to do it. It is not like they already have some hidden comments to do it and that by sending it in enough different forms might accidentally trigger one of them.

There is no way to solve this problem without changing the engines. And changing WinBoard engines to be configured by WinBoard options will be the most trivial change of all. It will be way easier than converting the engine to a UCI engine, and it will also be easier and more powerful than converting the engine to define and understand UCI options. Making a GUI understand UCI options from a WinBoard engine is thus totally superfluous. It does not make solving the problem in the engines for the engine authors any easier than it already is, and only creates problems on the GUI side that do not exist now.