H.G.Muller wrote:EugeneCarey wrote:You should also point out that this is an unofficial extension to the winboard / xboard protocol and that it's quite possible that Muller's hacked winboard may be the only one to ever support it.
Wrong:
it is the
official extension of the protocol for WinBoard version 4.3 and higher. Which I do consider the main branch of WinBoard development. If you thnk there will
ever be another version from Tim Mann's development team: keep on dreaming...
Caling it an "official extension" is an oxymoron.
If it's an official v2, then it's not an extension.
If it's an extension, then it can not be v2.
It's like saying it's a large tiny change to a program.
Or a safe, dangerous surgical procedure.
As to whether or not there will be another version from Tim Mann is irrelevant. Not even close to being relevant to the discussion.
His is the official version 2.
If you want to do your own version, then great. No problem.
If you want to fork your own and make radical or minor changes, then fine. Just don't call it v2, because it's not.
Call it v2.1 or v3 or whatever, but it's not v2.
Others may support it in the future, but until such time you are better off not sending any unexpected output.
There are already other GUIs that are suporting some of the protocol extensions I introduced, (e.g. ChessGUI).
I did say that others may support.
That means both ways.
And since Muller's extension is optional, you'll have to support the possibility that the winboard gui doesn't accept it, so why bother expecting it to exist?
Because if you make your engine send protocol-violating output, (as virtually every engine does for debugging purposes), it is always better to only crash some GUIs than to crash all GUIs. In general prefixing a protocol-violating line with '#' will not increase its probability to confuse any known GUI; in the worst case they just skip over the '#'.
I didn't say it was or was not a good idea.
It is a change that can potentially cause problems.
Do # for your v2.1 extensions and don't send any unsafe output when using v2 does require a change.
Sending # lines to a v2 gui when there's a chance it'll cause problems is just plain foolish. Hence for v2 you can't safely send any debugging etc. lines. You are right back where you started with real v2 winboard.
And since Muller made his own extensions (and still doing so), and still calling them v2, all it's really doing is causing confusion with the real, official v2 protocol.
Muller should have made them v3 instead of v2. Since he didn't, follow the real specs is my advice.
There is no danger of confusion, as the extensions are fully compliant with the existing v2 protocol.
There is a danger of confusion. Just look at this thread. Teemu, for example, though it was official winboard protocol.
The reaction of the GUI to receiving feature commands it does not recognize (e.g. like feature debug=1) is fully described by this protocol, and consists of rejected debug. The v2 protocol does not guarantee that every feature it defines will be implemented: it grants the GUI the right to refuse features.
I understand all that.
But you are still making private changes to an 'official' protocol.
And then trying to confuse people by keeping it as v2.
The v2 protocol says the listed features are v2.
The features you are including are not part of v2.
In fact, Tim Mann specifically made 'protover num' for future additions. Like the additions you are doing.
It's the same kind of nonsense that Microsoft regularly does. They take an official standard, modify the heck out of it, then claim it's still the standard because it has the same name.
Neither does it guarantee that every feature not in the original protocol definition will be rejected by the GUI. And even if it did, it seems a bit far-fetched to suppose that there will ever be an engine whose correct operation will depend on sending a nonexistent feature, and it then being rejected.
So if you can do something that work better in some cases, and never worse, do it. That is my advice...
And that means not sending any output that might confuse winboard. And it can happen. I've had it happen.
In practce everyone just does it anyway, because the risk is small, and
Not so small.
What happens is that most engines slowly change over time so they manage not to send risky output to the gui.
the benifit enormous. And if they are going to do it anyway, they might as well prefix it with a '#' and send the debug=1 feature... They can do
I'm not saying it's not a useful feature.
I'm just saying don't call it v2, because that's a lie.
that even if the feature is rejected, it would still be better than sending the lines without 'protection'. Because even if the GUI does not understand the '#' (e.g. because it is an obsolete WinBoard version), the lines will still end up in the debug file, and other programs that use the debug file (like TLCS) might benifit from the '#' prefix. It is more common for TLCS being confused by spurious engine output, than the GUI.
So my advice to engine authors is: never use the protocol v2 specification on Tim Mann's website, but always use mine. Then you can be 100% sure that your engine runs without problems on GUIs that only implement Tim Mann's version, but in addition it won't function sub-optimally when you are using a state-of-the-art GUI.
No, you won't be sure.
Your own suggestion of sending # output even if the GUI rejects and might get confused it is downright foolish & misguided.
Call your protocol v2.1 or v3 and that'll take care of my complaints.
I have no objections to the changes themselves.
My objections are you calling your personal version to be v2 when it is clearly not. It is based on v2, but it is not v2 anymore.
Call it 2.1, or 3.0beta or something else. But it's not the official v2 protocol.
You've taken winboard, decided to make significant changes to it and the protocol, and self claimed it to be the new official branch of winboard.
How can you possibly keep calling it v2, then??
Posted: 30 Oct 2008, 18:25