What should I support, UCI or Winboard?

[asimpereira]

Hi,

I am planning to include engine support in my Chess apps.
I have never worked on UCI or Winboard protocols before and hence wanted your opinion on what protocol should I support, to begin with.
Which protocol will be easier to work with?

Note I am NOT planning to write my own engine but just provide an interface to existing popular engines.

Regards,
Asim

[kinderchocolate]

That depends on what engine you want in your Android app?

[asimpereira]

I am thinking of first getting the protocol right such that I get familiarized with GUI-engine communication.
Then I will use any of the strong engines available in either of the protocols.

Do you think the approach is ok?

As I understand there are strong (and open source) engines in either category.

[hgm]

If you support one of the protocols, you could support the other through an adapter. Especially for GUI engines to run UCI engines there are exellent open-source adapters.

[kinderchocolate]

I don't think it's difficult to support a protocol if you can communicate with an engine. In terms of software engineering, you just need a design pattern where you implement an abstract interface. I've used it, and it's much more flexible than integrating the whole something like UCI2WB into the source. Up to you, I personally prefer an interface with some pure virtual functions.

[hgm]

I was not implying the adapters should be integrated in the source. In fact I think that is highly undesirable, because it would deny the user the choice of adapter, and the possibility to adapt it. That I mentioned their open-sourceness was only to indicate they can easily be made available on any platform.

The design with an abstract interface is also my guiding design principle for WinBoard. Except that the abstract interface in that case is identical to WB protocol, as it is the most potent of all protocls. This can then translated to other protocols (or at least the subset supported by those protocols) by adapters, which for flexibility are kept as independent programs, automatically invoked by the GUI.

[Matthias Gemuh]

On the GUI side, UCI is easy to support, WB is messy.
Look at permitted move formats, for example.

[hgm]

Indeed, that it is alowed to send SAN, or that an engine can even request the GUI sends SAN to it, is an abomination. OTOH, a GUI would need to be able to parse and generate PGN, and thus SAN to be any good. Using the routines required for that makes it almost zero work to apply them to the engine communication. So in practice the impact of this is not significant.

[Matthias Gemuh]

Indeed, that it is alowed to send SAN, or that an engine can even request the GUI sends SAN to it, is an abomination. OTOH, a GUI would need to be able to parse and generate PGN, and thus SAN to be any good. Using the routines required for that makes it almost zero work to apply them to the engine communication. So in practice the impact of this is not significant.

Mr Winboard ,

I expected you to defend your protocol !

However, UCI has only one move format, while WB will use combinations of the following scenarios :

- move in SAN format
- move in coordinate format
- move preceded by "usermove"
- move not preceded by "usermove"
- move preceded by "..."
- move not preceded by "..."
- etc.

... and move formats are not the only issue with WB.


UCI is simple.

[hgm]

I expected you to defend your protocol !

Why? It did not design most of it, and as a scientist I am usually very objective.

However, UCI has only one move format, while WB will use combinations of the following scenarios :

- move in SAN format
- move in coordinate format
- move preceded by "usermove"
- move not preceded by "usermove"
- move preceded by "..."
- move not preceded by "..."
- etc.

Well the "..." are of course an abomination. Actually, I dont think they are really part of WB protocol. They are merely documented tolerance of WinBoard for the non-compliance of GNU Chess. (Some GNU Chess versions, that is. Michel produced a decent one, nothing bad about that!) I would strongly recommend no other GUI implements that, and I am severely tempted to remove it from WinBoard as well. I am strongly against catering to non-compliant engines. (But I am too busy adding things to be bothered with removing things... )

The 'usermove' is a very good feature, and in the Alien Edition it proved essential for letting engines that support a wide variety of games with different move formats reliably generate Illegal-move messages. Unfortunately it was not in the protocol from the beginning. I admit the cost of maintaining backward compatibility can sometimes be high. But that is nothing compared to abandoning it.

... and move formats are not the only issue with WB.

You probably know that better than I: I never implemented WB protocol from the GUI side. From browsing through existing WB code, I got the impression that most of the complexity comes from going the extra lightyear to cater to non-compliant engines. I don't really consider that WB protocol, and if I wre to write a GUI from scratch that supported WB protocol, I would certainly not do such things. (E.g. sending 'hard' before 'easy', using 'white' + 'a2a3' to avoid using 'black'.) Basically all the 'idiom' stuff mentioned in the specs is obnoxious, and I would abandon it without hesitation. The 'black' and 'white' commands are superfluous for engines that support 'setboard', and I would never send them to such engines. If there are egines that would not work because of that, it must mean that they implemented other commands in a way that violated the specs, and that would just be to bad for them. Out they go!

UCI is simple.

Yeah, micro-Max is simple too. But it plays very poorly...

Perhaps it would be a good idea to rewrite the protocol specs, and more clearly brand a lot of things that are described there now as "deprecated, please do not use, please do not implement", and leave only a subset of the protocol ('modern WB protocol') that GUIs would have to support to run state-of-the-art engines. E.g. kicking out the 'edit' command, (oops. Fairy-Max uses that...) and require that the engine supports setboard, ping etc.