Ugly UCI

[SuneF]

Just to be clear, I did not say UCI is better because it's popular (which I think is implied by Bob's analogy). I said the best engines use it, so it must be "OK" (i.e. they must consider it does not weaken their engines).

- Steve

UCI is designed with a different usage in mind. It's a protocol that basically puts the GUI in charge and thus ultimately the user.
It seems to me to be designed for flexibility and analysis in mind.
The GUI play the book moves, the GUI does the learning, the GUI decides when you can ponder and if you got a ponder hit etc... The GUI becomes very much part of the game.

The winboard protocol is designed to allow the engine to be a "chess playing entity" of its own. The engine is in charge of everything, the book, the learning, what to ponder and when to ponder. It's all power to the engine.

The reason we don't agree on which protocol is the best is because we want different things. Many of us oldtimers don't want to just write analysis tools, we want to go all out and create battle bots for chess. An analysis feature is just a nice side affect, it's not the goal.

I don't hate the UCI protocol for what it is, I just think it has a different purpose than the winboard protocol. Sure you can work around the UCI protocol to still do some learning and such, but then you are basically working against the protocol and might as well just use winboard, IMHO.

[SuneF]

To claim support of a protocol version, you should however support the complete protocol, not a subset!

Why? I don't have to use all the features of a protocol to be able to claim I support it.
I support xboard and don't offer draws. I don't handle feature rejection and I don't see why I should add code to cover 0% of hypothetical cases where this would happen.
Works fine with winboard/xboard/cutechess.

A protocol is a contract, an interface between the engine and the outside world.
The bottom line is you don't know how the outside world reacts if you start lying to it.

In the case of draw offers, you can still claim support because the protocol doesn't specify you "have to offer draws" it just says you are "allowed to offer draws" so not offering draws is technically not a violation.

[mar]

The bottom line is you don't know how the outside world reacts if you start lying to it.

Lying?! If a GUI claims to support xboard protocol v2 and rejects setboard or time, then it's broken.
I haven't found such a GUI yet.

[SuneF]

The bottom line is you don't know how the outside world reacts if you start lying to it.

Lying?! If a GUI claims to support xboard protocol v2 and rejects setboard or time, then it's broken.
I haven't found such a GUI yet.

Yes the xboard protocol is not peer-to-peer, it's client-server.

Otherwise we wouldn't need the GUI at all, we could have the engines play eachother directly.
Not sure that would work but funny thought...

[stegemma]

[...]For variants where moves have side effects, like Ultima, these can be specified by the engine with parent variant 'alien', which does exactly what you propose (reply to each move with a FEN to indicate the new game state brought about by the move).[...]
My main point was that the existing WB protocol already contains what you propose, in its own way, and that some current versions of WinBoard already implement it.[...]

Maybe the problem is that I've based my interface on this old document, for xboard protocol:

https://www.gnu.org/software/xboard/engine-intf.html

and the "alien" option is not mentioned, there.

Where can I find the latest version?

[hgm]

Lying?! If a GUI claims to support xboard protocol v2 and rejects setboard or time, then it's broken.
I haven't found such a GUI yet.

I don't think that is true. Protocol v2 does explicitly allow GUIs to reject features. The only thing it promises over v1 is that the GUI will respond to every feature with an accept/reject. It is compliant to reject everything. But like you say, this is purely hypothetical.

Many aspects of the original v2 are really silly. That you can suppress sending of certain commands by colors=0 or time=0, for instance. That serves no point at all. Engines from before that spec that would crash on receiving times or colors were simply broken. It would require a repair action to make them emit time=0 or colors=0, and that would not be any easier than simply making it ignore these commands.

[Guenther]

UCI was already popular long before there existed something like Fruit or Glaurung.
I never used the xboard protocol at all, I went straight strait from a CLI and my own custom GUI to UCI somewhere in 2000/2001.
Sure, UCI has it flaws but xboard is not perfect either, it is just a matter of taste.

Sorry, it was not popular before Fruit arrived. Actually it was a kind
of 'heard of' minority thing, far below WB and even CB(which is finally
dead since even the last remaining Fritz diversed from it, but it
was no free protocol anyway).
I can easily derive stats from my old site RWBC up to a certain year.
(of course only for released programs - everything else would be just speculation
anyway)

Just sort by release date and see for yourself until Fruit appeared ;-)
http://rwbc-chess.de/wb_chron_date.htm

Guenther

[bob]

Poor logic. If that were true, then Windows must be the work of a genius and be better than any option. Give me Linux/Unix EVERY last time. The only virus I worry about is the Flu virus...

Indeed. It is pretty common in technology that the poorest system conquers the market. In our area of expertise of course Windows sticks out as an example. But it was also true for VCRs, and internal combustion engines are intrinsically inferior to Stirling engines, but virtually all cars still use them.

Technical quality hardly counts, it is all marketing. Almost to the point where the correlation becomes negative: "Almost everyone uses this, so it must be crap!"

Just to be clear, I did not say UCI is better because it's popular (which I think is implied by Bob's analogy). I said the best engines use it, so it must be "OK" (i.e. they must consider it does not weaken their engines).

- Steve

A GUI is unlikely to weaken an engine, except that in the case of chessbase, they did exactly this years ago. If you understand the xboard protocol, you would know that when the opponent makes a move, you relay that move to the program. Which meant back when that if you just said "new game" and then "sent move list" you would wipe out the hash table, wipe out anything learned during pondering, and basically make pondering pointless. It was a year or so before a couple of us received some games played via their GUI and discovered that this was going on. They KNEW.

I've simply always considered UCI as inferior. Trying to make a "stateless" interface for a "stateful" game made little sense when I first saw it. It requires kludges introduced into the program to avoid the restart penalty among other things. I won't go in to all the things I don't like about it, suffice it to say it is not something I want to deal with since, for me, xboard works flawlessly with no effort needed since it is already done.

[Evert]

I think UCI protocol needs to be updated

Personally, I think any protocol should never be updated.
Any update or new version creates another protocol. The main difficulty with Xboard/Winboard protocol that is constantly updated is that you do never know if your program, being a GUI or an engine is still compliant or not with a new addition.
IMHO, a protocol should have ZERO optional feature, it should be set in stone to be never updated, and be clear and concise.

That doesn't sound right to me. Times change, and so do demands on the functionality a protocol provides. If a protocol doesn't allow for this type of expansion it will become stale and obsolete.

Of course you can always make a completely new protocol to supercede the old one, but some measure of backward compatibility is desirable, at the very least during the transition period.

[tttony]

Well, UCI has not been updated for almost ten years, chess is changing