Ugly UCI

[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

[hgm]

That's why I qualified it as a dead protocol. Although it is clearly defective, attempts to repair the defects have come to nothing.

[abulmo]

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.

That is just not true. For one, XBoard protocol is never really updated, but only extended. And it is always extended in such a way that it is fully compatible with all previous versions. So programs that are compliant, be it GUIs or engines, will always remain compliant. It is just that they might look pretty stupid and user-unfriendly compared to engines that do use the protocol extensions, but they will continue to work in the way they did without problems.

You are playing with words.
An example of an update, that appeared recently in the protocol is the way to report mate scores. The new protocol text specifies:

Mate scores should be indicated as 100000 + N for "mate in N moves", and -100000 - N for "mated in N moves"

. "should" is really a strong word. So, to me, an engine that does not display mate scores this way is not compliant, and neither is a GUI that does not correctly interpret such scores. Of course, they may still be working, but they are actually not compliant to the present protocol.

[abulmo]

That's why I qualified it as a dead protocol.

dead is the wrong word here. UCI is not dead, because it is still in use today, and by very significant programs (the 10 best programs support only UCI).