Hello H.G.Muller : upgrading the protocol

[Matthias Gemuh]

There are two things which you seem not to value, but the chess community values a lot: backward compatibility with hundreds of engines and support for 100 weak (buggy) engines.
This limits flexibility of GUI programmers.

I don't think WB protocol 3 would help much.
However, a good new and powerful protocol that picks out only reasonable parts of WB and UCI and has new extensions too, would be great. It wouldn't have to be backward compatible to anything and would have to support not only standard chess.

Matthias.

I don't value backward compatibility when it is not required. protocol version 2 could remain "as is". Protocol version 3 would add the new things. And engine can always use protocol version 2. Just as they can currently stick with only version 1 if they choose.

I started a new thread with a pretty simple solution that is really not going to change anything, everything will continue to work as it currently does, except the GUI eliminates the race condition as we have previously discussed...

As a closing remark, remaining compatible with something that is already broken is not exactly a useful approach.

The vast majority of users expect all WB to have pretty much the same capabilities. They want to simply install WB engines (not WB1, WB2, WB3). To break away from previous versions in the minds of most users, WB3 would need a new name. Failure to have a new name means full backward compatibility is expected.

Matthias.

[hgm]

Is this an undocumented behavior of WB/XB? or is that a suggestion?

This is an undocumented behavior of WB 4.3.13 (?) and later, to prevent any problems with the rac condition, in accordance with the ïnnocent until proven guilty beyond reasonable doubt principle". If an engine could be possibly correct in its claim, it should not be possible to make it forfeit.

Except that it would be possible to make invalid claims. The engine can claim a draw that happened the previous move. I do not believe it is a good idea.

This is exactly why it is not documented. I don't want to encourage people ignoring the race condition. The recommended way is to stake your claim in advance by offer draw. This is the only way that would work in ICS play anyway, as the ICS has a mind of its own.

And the feature can be exploited: you could be forced to be the first to bring about the repetition, and hope that the opponent will try to avoid a 3-fold repetition when it is his turn, nd you see he has two plausible moves, one very good, but the other a blunder. You can then defer your claim until after he moves. If he continues to repeat, it is draw anyway. If he takes the blunder, you play on. But if he choses the winning move, you claim a draw in retrospect, and the GUI will never be able to prove that you did it after seeing the move, because of the race condition. Currently there are no engines that cheat this way. But I don't advertize this feature, because I don't want to give people ideas.

So like you say, that is bad. But it cannot be helped. Engines using the old protocol can either cheat or will frequently be unjustly forfeited, or valid draw claims will be denied to them. Not be able to catch the cheaters is the least of all evils. No protocol which offers backward compatibility can stop the cheating. You can define v3, v4, v100, and they can all be as safe as Fort Knox... And then the program that want to cheat will simply use v2 and switch off all your anti-cheating features. So we will have to live with the loophole that v2 offers, or abandon all engines now in existence.

[michiguel]

There are two things which you seem not to value, but the chess community values a lot: backward compatibility with hundreds of engines and support for 100 weak (buggy) engines.
This limits flexibility of GUI programmers.

I don't think WB protocol 3 would help much.
However, a good new and powerful protocol that picks out only reasonable parts of WB and UCI and has new extensions too, would be great. It wouldn't have to be backward compatible to anything and would have to support not only standard chess.

Matthias.

I don't value backward compatibility when it is not required. protocol version 2 could remain "as is". Protocol version 3 would add the new things. And engine can always use protocol version 2. Just as they can currently stick with only version 1 if they choose.

I started a new thread with a pretty simple solution that is really not going to change anything, everything will continue to work as it currently does, except the GUI eliminates the race condition as we have previously discussed...

As a closing remark, remaining compatible with something that is already broken is not exactly a useful approach.

The vast majority of users expect all WB to have pretty much the same capabilities. They want to simply install WB engines (not WB1, WB2, WB3). To break away from previous versions in the minds of most users, WB3 would need a new name. Failure to have a new name means full backward compatibility is expected.

Matthias.

Just for the record, a GUI could communicate with WB1 with one engine and WB3 with another. In fact, some GUIs can communicate with WB1 with one engine and UCI with another. WB3 will be backward compatible by definition. It will send protover 3 and the GUI will adjust

Miguel

[Matthias Gemuh]

Just for the record, a GUI could communicate with WB1 with one engine and WB3 with another. In fact, some GUIs can communicate with WB1 with one engine and UCI with another. WB3 will be backward compatible by definition. It will send protover 3 and the GUI will adjust

Miguel

You are telling me this because you have no idea what ChessGUI is capable of.

Matthias.

[michiguel]

Just for the record, a GUI could communicate with WB1 with one engine and WB3 with another. In fact, some GUIs can communicate with WB1 with one engine and UCI with another. WB3 will be backward compatible by definition. It will send protover 3 and the GUI will adjust

Miguel

You are telling me this because you have no idea what ChessGUI is capable of.

Matthias.

Why is what ChessGUI can or can't do relevant to my comment?

Miguel

[Matthias Gemuh]

Just for the record, a GUI could communicate with WB1 with one engine and WB3 with another. In fact, some GUIs can communicate with WB1 with one engine and UCI with another. WB3 will be backward compatible by definition. It will send protover 3 and the GUI will adjust

Miguel

You are telling me this because you have no idea what ChessGUI is capable of.

Matthias.

Why is what ChessGUI can or can't do relevant to my comment?

Miguel

If you knew what I have implemented in ChessGUI, you wouldn't reply me with that comment.

Matthias.

[michiguel]

Just for the record, a GUI could communicate with WB1 with one engine and WB3 with another. In fact, some GUIs can communicate with WB1 with one engine and UCI with another. WB3 will be backward compatible by definition. It will send protover 3 and the GUI will adjust

Miguel

You are telling me this because you have no idea what ChessGUI is capable of.

Matthias.

Why is what ChessGUI can or can't do relevant to my comment?

Miguel

If you knew what I have implemented in ChessGUI, you wouldn't reply me with that comment.

Matthias.

In case you did not notice, my comment was on what was written here. In fact, it is even irrelevant whether you write it or someone else.

Miguel

[bob]

There are two things which you seem not to value, but the chess community values a lot: backward compatibility with hundreds of engines and support for 100 weak (buggy) engines.
This limits flexibility of GUI programmers.

I don't think WB protocol 3 would help much.
However, a good new and powerful protocol that picks out only reasonable parts of WB and UCI and has new extensions too, would be great. It wouldn't have to be backward compatible to anything and would have to support not only standard chess.

Matthias.

I don't value backward compatibility when it is not required. protocol version 2 could remain "as is". Protocol version 3 would add the new things. And engine can always use protocol version 2. Just as they can currently stick with only version 1 if they choose.

I started a new thread with a pretty simple solution that is really not going to change anything, everything will continue to work as it currently does, except the GUI eliminates the race condition as we have previously discussed...

As a closing remark, remaining compatible with something that is already broken is not exactly a useful approach.

The vast majority of users expect all WB to have pretty much the same capabilities. They want to simply install WB engines (not WB1, WB2, WB3). To break away from previous versions in the minds of most users, WB3 would need a new name. Failure to have a new name means full backward compatibility is expected.

Matthias.

You realize that normal winboard/xboard works with _both_ protocol version 1 and version 2? The engine and GUI negotiate as to which to use.

[bob]

Computers _can_ play according to FIDE rules. Mine does. I chose to do that because I do play in human events here and there and have to play by the rules being used. We now have a slightly different game than real chess we are playing, because it seems appropriate (to some) to modify the rules a bit rather than fixing the protocol to closely follow the rules for the game we are supposed to be playing.

Only a completely new protocol helps, otherwise backward compatibility becomes a real headache inside the GUI.

Matthias.

Something is getting lost here. For years we had "winboard/xboard". Tim and I (and others) worked on adding new features, but to maintain backward compatibility we went with the "protover n" command so that the engine can tell winboard/xboard that they can use the new protocol features (done, etc), otherwise the original protocol is all that is used. This would be protocol version 3. Surely your GUI protocol handling code can be modified? Worst case is to duplicate the current code and if the engine says "protover 2" then use the current code, otherwise use the newer code.

The entire purpose of software is to be adaptable. The idea of "it works so let's not change it" is completely foreign to me, when one can demonstrate clear and obvious flaws that need repair.

[Matthias Gemuh]

You realize that normal winboard/xboard works with _both_ protocol version 1 and version 2? The engine and GUI negotiate as to which to use.

Yes, but there are things WB2 engines are functionally capable of, that WB1 engines aren't. The majority of users think the GUI can "emulate" the missing functionality, so that the user should see no functional differences.

When WB3 comes along, all it offers will be expected of all WB engines, after all, WB3 is WB. Those expectations vanish when protocol name changes. That's the best way to drop cumbersome backward compatibility.

Matthias.