Ist bei UCI aber kein optionaler Teil, also vergleiche ich auch gleiche Funktionalität bei xboard. Zumal das ja auch nur ein Beispiel für die Redundanz bei xboard ist, und wie gesagt, die läßt Testing und Support explodieren. Kein Wunder, wieso das besonders für kommerzielle Engines inakzeptabel ist.

Auch die Features, die dann in der GUI auftauchen, kamen erst in xboard rein, weil UCI vorgeprescht ist. Vorher hat man die Nutzer auf abstruse ini-Dateien und ebenso obskure Kommandozeilenparameter verwiesen nach dem Motto "friß oder stirb".

Die Protokollversion wird aber von der GUI und nicht von der Engine festgelegt. Die GUI kann auch mit "reject" reagieren. Protover 2 ist kein Ersatz für Version 1, sondern eine Ergänzung.

Übrigens, ein lustiges Detail am Rande: GNUchess, dessen Befehlssatz das xboard-Protokoll emuliert, bietet jetzt auch UCI-Support. Über diese Möglichkeit hatte ich auch nachgedacht, zumal ja schon xboard-Support in der Engine drin war, wenngleich unvollständig und nicht sehr robust. Deswegen kam ich ja erst auf xboard, weil ich das "mal eben schnell" wieder reinbauen konnte.

Die Konsequenz wäre aber noch mehr Redundanz gewesen, noch mehr Testing, noch mehr unklare Bugreports. Zumal Vermeidung redundanter Methoden gerade der Witz bei UCI ist.

Zuguterletzt hat UCI auch den ganz praktischen Vorteil, daß es das besser unterstützte Protokoll ist. Ich glaube nicht, daß man in DGT Pi, Revelation oder Grandmaster auch noch xboard reinbasteln wird. UCI ist drin, weil Stockfish UCI ist. Man könnte mit Adaptern arbeiten - und ist dann wieder in der Misere aus Testaufwand und Support.

Wenn ein Protokoll mehr Aufwand für Test und Support verlangt, dann muß es auch einen entsprechenden Mehrwert liefern. Bei gleichem Nutzwert ist es sonst allein deswegen schon raus. Die Rankinglisten legen auch nicht nahe, daß UCI-Engines an ihrem Protokoll leiden würden.