UCCI2WB

[syzygy]

Also, in my interpretation of the master/slave relationship, the GUI is the slave, which relays the input from the user to its master and displays whatever information the engine decides it should display.

In UCI clearly the engine is the slave.

But master/slave is just part of the UCI philosophy. The other part is that the engine is limited to calculating moves (and time management, somewhat surprisingly maybe) and that the GUI takes care of everything else (book handling, draw offers, draw/mate detection, etc.)

[hgm]

That is obviously a broken philosophy, as the GUI doesn't have the knowledge to decide about draw offers. Only an engine could make that decision. You might as well let the GUI decide on the promotion choice...

[bob]

If there is only one legal move, the GUI could just make it and not bother the engine. In fact, it wouldn't even have to start the clock.

Once the GUI makes a game decision, it is no longer a GUI. That "I" in GUI has a very distinct meaning, it is supposed to simply serve as an interface between the user and the engine, using a graphical board to display/accept moves. The GUI has no business playing moves from book, doing book learning, making instant moves, handling/offering draws and such. Those are decisions that affect the game and they are things which only the engine should handle. It is the one actually playing the game, not the GUI.

[wgarvin]

If there is only one legal move, the GUI could just make it and not bother the engine. In fact, it wouldn't even have to start the clock.

Once the GUI makes a game decision, it is no longer a GUI. That "I" in GUI has a very distinct meaning, it is supposed to simply serve as an interface between the user and the engine, using a graphical board to display/accept moves. The GUI has no business playing moves from book, doing book learning, making instant moves, handling/offering draws and such. Those are decisions that affect the game and they are things which only the engine should handle. It is the one actually playing the game, not the GUI.

Yeah, thats something I've always hated about UCI. The way I see it, an "engine" should be a complete game-playing program, capable of playing all phases of the game, from first move to endgame, without decision-making assistance from the GUI.

It just seems wrong to me to put any of the game-playing logic on the GUI side, the way UCI does. It may be convenient for commercial vendors whose offering consists of several proprietary engine backends bundled with a common front-end, but I think its a lousy choice for everybody else.

The reasons for dividing "engine" and "GUI" into two separate programs, should be:
(1) so the same GUI can be re-used with different engines,
(2) so that the engine code is more portable between different platforms, and
(3) so engine authors can focus on making their program play chess without having to also become GUI programmers, or to re-implement all of the work already done by the authors of existing GUIs.

Users should be able to take any engine(s) from different authors and plug them into a standard-compliant GUI and they should just work, and the engine's game-playing ability should not depend on GUI-provided books or tablebases. Imagine playing an engine tournament where several of the engines are using the same GUI and receiving the same assistance from the same books, etc.

GUIs should be purely about the presentation of the game to a human player or observer, and communicating moves or instructions from the human user to the engine(s). The engines should do all of the game-playing, including managing their time and choosing their own moves. If users want to use the same books or tablebases with different engines, GUIs should accomodate that by telling the engine where to find those books or tablebases--but not by reading the book itself and spoon-feeding moves to the engine.

...not that the xboard protocol is any shining gem either, but at least it gets the engine/GUI division right. It would be nice if everybody had standardized on one protocol, and if xboard had been that protocol I could live with that. But UCI is quite popular with engine developers, so we're stuck with both protocols for the forseeable future. And I guess with adapters like Polyglot and UCI2WB around, its not a big deal... I suppose users are able to use almost any engine with the GUI of their choice.

[mvk]

UCI does not allow engines to offer or accept a draw. Right or wrong?
FIDE rules do specify you can offer a draw with any move. Right or wrong?

FIDE rules also require that moves must be made by hand (rule 4.1), and UCI doesn't support that either. And that is not a problem, because on the first page it states: "FIDE Laws of Chess cover over-the-board play". Therefore not the play in a computer's memory, or on a computer network.

I dislike both protocols myself. UCI for the reasons that Bob give, it doesn't cover important game playing decisions. The xboard protocol because the option system is too complicated, for both sides of the protocol.

Just have to live with it I guess... At least both are well documented.

[PK]

IMHO objection against opening book goes a bit too far - not every programmer will get it right, or at least it is easy to come up with a solution that seems to work OK-ish but then slows down unacceptably on larger files. Besides that, there are users who want to see an engine to play, say, Elephant's gambit, and it is better if they have to learn one solution per GUI than one solution per engine. On the other hand, if a programmer wants to do something creative with book moves, then by all means it is a superior solution.

[hgm]

I don't see much harm in a design where the game-playing code is not necessarily a single program, but van be divided over several specialist programs. Like a program for playing while in book, and one for playing out of it. Most book formats do not need search while in book, most searches do not use book info. And if all 'book engines' have some mechanistic code in common for probing them, I don't see any harm in moving that to the GUI, to save everyone a bit of work.

Note that being 'based on a philosophy' doesn't necessarily make a protocol any better. It is in fact a limitation, because a protocol can only be as good as the philosophy it is based on. Having to comply with the philosophy is a restiction. So if the philosophy sucks, the protocol based on it can never rise above the level of useless crap. A philosophy that divides the resposibility for handling white an black pieces over two different engines, allowing the white engines to see only white moves and the black engine to see only black moves might be a great anti-cheat design for Kriegsspiel, but would be utterly unsuitable for Chess.

I can add to that that we don't really know what philosophy UCI is based on. Only the protocol specs are published, and any claims on the undelying philosophy are based on reverse-engineering of it. Which then of course elevates mere oversights in the specs to some deep (but very counterproductive) 'philosophy'.

[Evert]

In UCI clearly the engine is the slave.

That is obviously the expected answer to the question I posed earlier. I contend that this is not a necessary or universally obvious answer.

What is certainly true is that UCI for the most part treats the engine as a dumb calculator that spits out moves in a given position, while CECP is more an interface for a chess program to talk to a GUI. Obviously both designs reflect the history of the respective protocol.

For myself, my own programs are never dumb calculators. They're designed so you can play them fairly easily in console mode. As such, CECP is a (much) better match to how they work than UCI is, and I personally prefer CECP for that reason.

Either approach has its advantages and disadvantages and in the end, either approach clearly works. In the end of the day, to implement either protocol you follow (and comply with) the specs and that's that. Let's not pretend there's anything more to "understand" about either protocol than that.

Also (and this is not aimed at anyone in particular, just a pre-emptive statement), let's remember that disagreeing about something isn't the same as not understanding something.

The other part is that the engine is limited to calculating moves (and time management, somewhat surprisingly maybe) and that the GUI takes care of everything else (book handling, draw offers, draw/mate detection, etc.)

Sure. That extends to illegal chase moves in Xiangqi for UCCI.
Whether these are good ideas or not is an entirely different discussion. Do you think the UI could handle time management for the engine? You say it's "somewhat surprising" that this is up to the engine, suggesting that you think it could or should. I'm not sure I believe that.

People say that UCI is a "stateless" protocol where the engine just gets told what to do and does not have to remember anything in between. This is certainly not entirely true in practice (leaving aside the question of whether it really is meant to be or not) because in order for it to be people would have to clear out their transposition tables and killer tables before each "go" command - which would generally not be a very good idea.

[Evert]

Once the GUI makes a game decision, it is no longer a GUI. That "I" in GUI has a very distinct meaning, it is supposed to simply serve as an interface between the user and the engine, using a graphical board to display/accept moves. The GUI has no business playing moves from book, doing book learning, making instant moves, handling/offering draws and such. Those are decisions that affect the game and they are things which only the engine should handle. It is the one actually playing the game, not the GUI.

I agree. To be clear, I was actually playing a snarky Devil's advocate when I said that the GUI could just play the only move if there is only one. I don't think a GUI has any business doing that, but then again, I don't think it has any real business doing that for book or tablebase moves either - because in the master/slave analogy, I think it's the GUI that should be the slave rather than the engine (I actually dislike the term "engine" for a chess program, but that's perhaps just me).

[Evert]

The xboard protocol because the option system is too complicated, for both sides of the protocol.

I agree with the Engine->GUI side of the exchange, but the GUI->Engine side is just "option name=value". I'm not sure how that could be reasonably simplified?

The main "problem" I have/had with CECP is the compatibility cruft you don't have to worry about in the specification. It's easy to ignore once you know you can, but it would be useful to have a "simple" document that leaves all that out. I guess some of the commands don't exactly have optimal names either ("easy", "hard", "bk" is pretty bad too, particularly since the spec doesn't say what it should actually do).