Hello H.G.Muller : upgrading the protocol

[hgm]

You say that there is no need for modifications of the protocol, but the fact is that you modified it. "offer draw" and 1/2-1/2 is not what it used to be.

I disagree. 1/2-1/2 and offer draw are still exactly what they are supposed to be as described in th protocol; 1/2-1/2 for terminating games, offer draw for requesting a draw to be granted (e.g. accepting a draw offer). It is only XBoard the implementation of it that has changed, within the freedom (some would ay ambiguity) the protocol specs allowed, or by removing obvious bugs from the old implementation.

Now it is much tighter. That is fine, but what I am requesting is that my engine has the ability to know whether the GUI will have this tighter interpretation, that basically changes the behavior of choice.
It used to be that claims were 1/2-1/2, now it is "offer draw".

Not really. Claims are still 1/2-1/2, in positions where you have the right to claim. Because when you have the right to claim, the draw will certainly be granted, and it is safe to terminate the game. In ICS play, the old protocol also required you to offer a draw to the ICS before making the drawing move, to pre-empt the race condition.

As an engine, I want to know what I am dealing with. Your proposed solution is that I act as I do not know what type of XB protocol I am facing and send commands to cover any possibility. offer draw for the new behavior, 1/2-1/2 for the old one.

Exactly. That is the protocol requirement. That you might be able to get away with sending only one of those is a property of the implementation, that is not specified in the protocol. Future implementations might behave differently than both the old and the new implementation. E.g. it might require both commands to be send. That would not constitute a change of the protocol.

Is that much to ask a simple feature that bounce back with accepted telling me that I am dealing with this new behavior?

Then I could send offer draw if accepted with confidence, without the 1/2-1/2 (which is risky).

In other words, the questions is, what is the problem with sending accepted to a feature atomicoffers=1?

Yes, that is asking to much: I consider that a very bad feature. It would allow te engine to ask questions about the implementation, so it could figure out in what ways exactly it can violate protocol and get away with it. (Or how it could cheat.) Engines should stick to the protocol, so they can be kept unaware of the implementation details. Leaving that Golden Rule will only promote future incompatibilities.

Miguel

It has a direct relationship to what I would do. If I know that I am dealing with this tighter interpretation, I would never send 1/2-1/2 for 3 fold rep. or 50 moves rule. Otherwise, I would be extremelly careful in my claims.

Your concern is not justified. It should always be possible to send a 1/2-1/2 claim if FIDE rules say you can make one in the current position. GUIs that would not accept such claims are badly broken. Do not try to hide their errors by colluding with them in violating the protocol. This will only lead to Chaos, in he long run. Just do not send 1/2-1/2 clams in positions that are not legal draws.

That you have to send something before your move that translates to a draw offer in ICS mode is not something that can be helped anyway; it is the ICS that requires that.

[bob]

You say that there is no need for modifications of the protocol, but the fact is that you modified it. "offer draw" and 1/2-1/2 is not what it used to be.

I disagree. 1/2-1/2 and offer draw are still exactly what they are supposed to be as described in th protocol; 1/2-1/2 for terminating games, offer draw for requesting a draw to be granted (e.g. accepting a draw offer). It is only XBoard the implementation of it that has changed, within the freedom (some would ay ambiguity) the protocol specs allowed, or by removing obvious bugs from the old implementation.

1/2-1/2 does _not_ work. Been there. Done that. Got the T-shirt.

Hint: think race condition and Qh7 followed by 1/2-1/2 because of the 50 move rule. Unfortunately my opponent has already played Kxh7 and the 50 move counter has been reset.

Now it is much tighter. That is fine, but what I am requesting is that my engine has the ability to know whether the GUI will have this tighter interpretation, that basically changes the behavior of choice.
It used to be that claims were 1/2-1/2, now it is "offer draw".

Not really. Claims are still 1/2-1/2, in positions where you have the right to claim. Because when you have the right to claim, the draw will certainly be granted, and it is safe to terminate the game. In ICS play, the old protocol also required you to offer a draw to the ICS before making the drawing move, to pre-empt the race condition.

Does this mean that if I play Qh7+, and send 1/2-1/2, but you receive the move Kxh7 from my opponent before you receive my 1/2-1/2 that you are going to agree it is a draw? And you are not going to send _me_ a bogus move like Kxh7 which is not legal because I have already claimed that the game is over, correctly?

Too many holes.

As an engine, I want to know what I am dealing with. Your proposed solution is that I act as I do not know what type of XB protocol I am facing and send commands to cover any possibility. offer draw for the new behavior, 1/2-1/2 for the old one.

Exactly. That is the protocol requirement. That you might be able to get away with sending only one of those is a property of the implementation, that is not specified in the protocol. Future implementations might behave differently than both the old and the new implementation. E.g. it might require both commands to be send. That would not constitute a change of the protocol.[/quote]

Somehow we have a totally different definition of "protocol". Good protocols are explicit with no room for variability. Poor protocols are weakly specified and leave too much to choice and introduce too many issues. A protocol does not "might require. Or might not require." It _does_ require, or it _does not allow_. Anything else is a poor specification. Software Engineering 101. If TCP/IP, or UDP were that poorly defined, we would not even be able to have this discussion.

Is that much to ask a simple feature that bounce back with accepted telling me that I am dealing with this new behavior?

Then I could send offer draw if accepted with confidence, without the 1/2-1/2 (which is risky).

In other words, the questions is, what is the problem with sending accepted to a feature atomicoffers=1?

Yes, that is asking to much: I consider that a very bad feature. It would allow te engine to ask questions about the implementation, so it could figure out in what ways exactly it can violate protocol and get away with it. (Or how it could cheat.) Engines should stick to the protocol, so they can be kept unaware of the implementation details. Leaving that Golden Rule will only promote future incompatibilities.

Miguel

It has a direct relationship to what I would do. If I know that I am dealing with this tighter interpretation, I would never send 1/2-1/2 for 3 fold rep. or 50 moves rule. Otherwise, I would be extremelly careful in my claims.

Your concern is not justified. It should always be possible to send a 1/2-1/2 claim if FIDE rules say you can make one in the current position. GUIs that would not accept such claims are badly broken. Do not try to hide their errors by colluding with them in violating the protocol. This will only lead to Chaos, in he long run. Just do not send 1/2-1/2 clams in positions that are not legal draws.

That you have to send something before your move that translates to a draw offer in ICS mode is not something that can be helped anyway; it is the ICS that requires that.

[bob]

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.

That's why there are specifications. IPV4 vs IPV6 as but one example. You can use either one you choose. And you are forced to follow the rules of the one you choose, and you only get the capabilities that offers. I think most users are smart enough to figure that out. It has certainly worked for WB protocol for years. Most start off with protover 1 for simplicity to get a quick testing mechanism in place. They add protover 2 when they realize the advantages of the increased functionality.

[Matthias Gemuh]

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.

That's why there are specifications. IPV4 vs IPV6 as but one example. You can use either one you choose. And you are forced to follow the rules of the one you choose, and you only get the capabilities that offers. I think most users are smart enough to figure that out. It has certainly worked for WB protocol for years. Most start off with protover 1 for simplicity to get a quick testing mechanism in place. They add protover 2 when they realize the advantages of the increased functionality.

We may not understand each other.
I talk about "dumb" users who don't know what a protocol is.
Your reply focusses on those who can differentiate between protocol versions.

Matthias.

[hgm]

1/2-1/2 does _not_ work. Been there. Done that. Got the T-shirt.

Hint: think race condition and Qh7 followed by 1/2-1/2 because of the 50 move rule. Unfortunately my opponent has already played Kxh7 and the 50 move counter has been reset.

That was not the point. The point was if the specs were changed. If it did not work before, and it still dos not work now, it is not changed... And if the specs say it should not work, and it does in fact not work, then it works according to specs.

Does this mean that if I play Qh7+, and send 1/2-1/2, but you receive the move Kxh7 from my opponent before you receive my 1/2-1/2 that you are going to agree it is a draw? And you are not going to send _me_ a bogus move like Kxh7 which is not legal because I have already claimed that the game is over, correctly?

No, it does mean that. If you claim by 1/2-1/2 your claim might be too late, and occur after the move Kxh7. So Kxh7 is not really a bogus move, and you might receive it even before you sent the claim. It only means that the draw will be granted. If you don't want bogus moves, you should offer draw before the move.

But that dos not mean the protocol has been changed. It never specified whether you would get bogus moves or not, in reaction to any command.

Too many holes.

We will have to live with that, because old specs of the protocol define this as a legal way for claiming draws. So the burdon to make sure that it works for exiting engines that do things this way is on the GUI writer.

Somehow we have a totally different definition of "protocol". Good protocols are explicit with no room for variability. Poor protocols are weakly specified and leave too much to choice and introduce too many issues. A protocol does not "might require. Or might not require." It _does_ require, or it _does not allow_. Anything else is a poor specification. Software Engineering 101. If TCP/IP, or UDP were that poorly defined, we would not even be able to have this discussion.

OK, so WB protocol is a poor protocol, as it is weakly specified. Too bad. We will still have to live with that.

[bob]

1/2-1/2 does _not_ work. Been there. Done that. Got the T-shirt.

Hint: think race condition and Qh7 followed by 1/2-1/2 because of the 50 move rule. Unfortunately my opponent has already played Kxh7 and the 50 move counter has been reset.

That was not the point. The point was if the specs were changed. If it did not work before, and it still dos not work now, it is not changed... And if the specs say it should not work, and it does in fact not work, then it works according to specs.

Does this mean that if I play Qh7+, and send 1/2-1/2, but you receive the move Kxh7 from my opponent before you receive my 1/2-1/2 that you are going to agree it is a draw? And you are not going to send _me_ a bogus move like Kxh7 which is not legal because I have already claimed that the game is over, correctly?

No, it does mean that. If you claim by 1/2-1/2 your claim might be too late, and occur after the move Kxh7. So Kxh7 is not really a bogus move, and you might receive it even before you sent the claim. It only means that the draw will be granted. If you don't want bogus moves, you should offer draw before the move.

Have you ever played chess OTB? No chessplayer in their right mind would think that is a reasonable solution. It is not hard to make the GUI deal with the draw claim before the move, or the draw claim or draw offer after the move, and throw away the extra move once things are verified. I certainly don't get any extra moves in my PGN games from testing. The proper way to offer a draw is to make your move, say "I offer you a draw" and then press the clock button. We don't have the "button" to press, but we can do this logically and clearly.

But that dos not mean the protocol has been changed. It never specified whether you would get bogus moves or not, in reaction to any command.

Sorry, but the protocol does not include a unified field theory or anything else. The PGN specification is quite clear that it only includes moves played in the real game. One cane not play a move after I make a valid claim of repetition or 50 move draw. So the protocol has no business mentioning the PGN. That's already specified _elsewhere_. Don't try to extend the xboard protocol to cover things it does not address at all. Doesn't even mention the PGN tags that are required or anything else.

Too many holes.

We will have to live with that, because old specs of the protocol define this as a legal way for claiming draws. So the burdon to make sure that it works for exiting engines that do things this way is on the GUI writer.

OK, this is going nowhere. I suppose we should consider, from this date forward, that Crafty is no longer going to be winboard compatible. I have a functioning version of xboard that I will simply rename and distribute with Crafty so that it plays legal chess according to FIDE rules, using a protocol that I consider to be more rational. Maybe others will feel the same way and decide to use a GUI that has a "fixed" protocol that doesn't look it was designed in a closet with no chessplayer input.

Somehow we have a totally different definition of "protocol". Good protocols are explicit with no room for variability. Poor protocols are weakly specified and leave too much to choice and introduce too many issues. A protocol does not "might require. Or might not require." It _does_ require, or it _does not allow_. Anything else is a poor specification. Software Engineering 101. If TCP/IP, or UDP were that poorly defined, we would not even be able to have this discussion.

OK, so WB protocol is a poor protocol, as it is weakly specified. Too bad. We will still have to live with that.

No "we" don't.

[bob]

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.

That's why there are specifications. IPV4 vs IPV6 as but one example. You can use either one you choose. And you are forced to follow the rules of the one you choose, and you only get the capabilities that offers. I think most users are smart enough to figure that out. It has certainly worked for WB protocol for years. Most start off with protover 1 for simplicity to get a quick testing mechanism in place. They add protover 2 when they realize the advantages of the increased functionality.

We may not understand each other.
I talk about "dumb" users who don't know what a protocol is.
Your reply focusses on those who can differentiate between protocol versions.

Matthias.

Why do dumb users even care. My wife uses the internet every day and has no clue what the acronym TCP/IP means. Only engine _authors_ care about the protocol. Why would users care?

[hgm]

OK, this is going nowhere. I suppose we should consider, from this date forward, that Crafty is no longer going to be winboard compatible. I have a functioning version of xboard that I will simply rename and distribute with Crafty so that it plays legal chess according to FIDE rules, using a protocol that I consider to be more rational. Maybe others will feel the same way and decide to use a GUI that has a "fixed" protocol that doesn't look it was designed in a closet with no chessplayer input.

That is entirely upto you. Anyone can start his own fork of xboard, and change the communication protocol to whatever they want.

You could even call it WB protocol v3, and make sure engines using protocol v2 could still use your XBoard. I am not interested in developing a new protocol version, as I am quite comfortable with v2.

[bob]

OK, this is going nowhere. I suppose we should consider, from this date forward, that Crafty is no longer going to be winboard compatible. I have a functioning version of xboard that I will simply rename and distribute with Crafty so that it plays legal chess according to FIDE rules, using a protocol that I consider to be more rational. Maybe others will feel the same way and decide to use a GUI that has a "fixed" protocol that doesn't look it was designed in a closet with no chessplayer input.

That is entirely upto you. Anyone can start his own fork of xboard, and change the communication protocol to whatever they want.

You could even call it WB protocol v3, and make sure engines using protocol v2 could still use your XBoard. I am not interested in developing a new protocol version, as I am quite comfortable with v2.

Some like anti-Darwinianism. I prefer to address problems as they surface, as if you do this often enough, the problems disappear.

[michiguel]

You say that there is no need for modifications of the protocol, but the fact is that you modified it. "offer draw" and 1/2-1/2 is not what it used to be.

I disagree. 1/2-1/2 and offer draw are still exactly what they are supposed to be as described in th protocol; 1/2-1/2 for terminating games, offer draw for requesting a draw to be granted (e.g. accepting a draw offer). It is only XBoard the implementation of it that has changed, within the freedom (some would ay ambiguity) the protocol specs allowed, or by removing obvious bugs from the old implementation.

Now it is much tighter. That is fine, but what I am requesting is that my engine has the ability to know whether the GUI will have this tighter interpretation, that basically changes the behavior of choice.
It used to be that claims were 1/2-1/2, now it is "offer draw".

Not really. Claims are still 1/2-1/2, in positions where you have the right to claim. Because when you have the right to claim, the draw will certainly be granted, and it is safe to terminate the game. In ICS play, the old protocol also required you to offer a draw to the ICS before making the drawing move, to pre-empt the race condition.

As an engine, I want to know what I am dealing with. Your proposed solution is that I act as I do not know what type of XB protocol I am facing and send commands to cover any possibility. offer draw for the new behavior, 1/2-1/2 for the old one.

Exactly. That is the protocol requirement. That you might be able to get away with sending only one of those is a property of the implementation, that is not specified in the protocol. Future implementations might behave differently than both the old and the new implementation. E.g. it might require both commands to be send. That would not constitute a change of the protocol.

I think I am even more confused now what it required and what is not.

In the sequence (as you suggest)

offer draw
move Rh7+
1/2-1/2

Is 1/2-1/2 a workaround to maximize backward compatibility with older GUIs or a requirement of the protocol? you talk here like it is a requirement but where is that in the protocol? unless I missed something, the protocol specifies that I should do offer draw & move Rh7+ and it does not look 1/2-1/2 is required.

Also, with the old winboard, offer draw was not used to claim draws, now it does.

This change in behavior constitute a modification of the protocol in my opinion.

Miguel

Is that much to ask a simple feature that bounce back with accepted telling me that I am dealing with this new behavior?

Then I could send offer draw if accepted with confidence, without the 1/2-1/2 (which is risky).

In other words, the questions is, what is the problem with sending accepted to a feature atomicoffers=1?

Yes, that is asking to much: I consider that a very bad feature. It would allow te engine to ask questions about the implementation, so it could figure out in what ways exactly it can violate protocol and get away with it. (Or how it could cheat.) Engines should stick to the protocol, so they can be kept unaware of the implementation details. Leaving that Golden Rule will only promote future incompatibilities.

Miguel

It has a direct relationship to what I would do. If I know that I am dealing with this tighter interpretation, I would never send 1/2-1/2 for 3 fold rep. or 50 moves rule. Otherwise, I would be extremelly careful in my claims.

Your concern is not justified. It should always be possible to send a 1/2-1/2 claim if FIDE rules say you can make one in the current position. GUIs that would not accept such claims are badly broken. Do not try to hide their errors by colluding with them in violating the protocol. This will only lead to Chaos, in he long run. Just do not send 1/2-1/2 clams in positions that are not legal draws.

That you have to send something before your move that translates to a draw offer in ICS mode is not something that can be helped anyway; it is the ICS that requires that.