CECP ('WB protocol') specs

[hgm]

This kind of undefined behaviour is not suitable for an interface definition.

Why? None of the commands are required to have a relation of their parameters with that of a previous issue. You can request a 5-min sudden-death game with a 'level' command without first doing 1-, 2-, 3- and 4-min games. So the order of TCs in level commands is not defined. Is that not suitable? If it is, why wouldn't it be suitable for 'ping'?

The whole idea of a protocol or a language is that it leaves almost everything of the higher-order structure undefined, so that by ordering the words you have infinite expressive power, rather than just a finite number of sentences that were defined.

Just say in the specs: "The ping number N that the gui sends starts with 1
at the first ping and increments N by 1 with every other ping."

Then the engine can use an unsigned int to store the number N, initialize it with 0,
and detect errors easily.

It is not the task of an engine to catch errors of the GUI. It is the task of the GUI to not make any errors. What you propose is first redefining things that were perfectly allright and could not possibly be wrong as errors, and then putting the burden on engines to try to catch those errors. Much better would be if engines just worried about their own errors, and simply obeyed the commands the GUI sent them in the way the protocol prescribes.

[kbhearn]

usermove allows a bit more laziness if you're prepared to trust the gui. whatever comes after it must be a move, so you feed it into your move parser that trusts it and you're done. without usermove trusting the gui is out of the question as it may in fact just be an unknown command so your move parser has to validate that it's a move and not just assume characters are in the valid range and do some addition and subtraction.

that said, i don't think it's the most important feature - but if it's there it should either fall in the 'gui shouldn't reject' or 'deprecated' category rather than leave people who want to use it wondering if they should or not.

[michiguel]

I made a draft for a new specification document of CECP, attempting to get rid of anything that is general programming advice on how to implement pipe I/O, and stuff that only describes XBoard peculiarities. I do not consider it 100% finished, but except for very rare or never-implemented stuff, most should be there now.

I would like to have some feedback on whether this is indeed a step in the right direction, or what else could be done to improve the presentation.

I suggest to have in the main document only the preferred way of doing things, and in an appendix the alternatives. For instance, I think if "setboard" is present, "edit" does not belong to the main document as well as "white", "black" etc.

I know you like variants, but it is better if the sample dialog is for "normal", which is what the majority would be using. You can give another example for a variant.

Miguel

[hgm]

I suggest to have in the main document only the preferred way of doing things, and in an appendix the alternatives. For instance, I think if "setboard" is present, "edit" does not belong to the main document as well as "white", "black" etc.

That was my original intention, but it turned out that there is no "etc.", and that it is really only "edit" and "white/black". Considering the size the 'main' document would have already without those, there seemed no real gain in omitting the two paragraphs describing them, and a bit silly to create a separate document for just three commands with 8 lines description in total.

The real problem is not obsolete commands, but the commands I labeled as "advanced", that almost no one would want to use because of their very specialized function (communicating with an ICS, doing opponent modelling, engaging in a direct dialog with the user...) Of those there are a lot, and there could be even more. (E.g. I am in doubt of whether I should label option features as "advanced", and perhaps also draw negociation.)

In the latest version I use background coloring (light yellow for obsolete, and sky blue for advanced) to encourage the reader to skip sections that are likely to be of no relevance to him. Roughly speaking the secitions 'handshake' and 'basic gui-to-engine' + 'basic engine-to-gui' coincide with Matthew's 'Core' commands, and 'setting engine parameters', 'time control' and 'analysis' with his 'Additional commands'. I don't think that setting the engine parameters through memory, easy/hard or cores is any less fundamental than 'setboard'.

[JoshPettus]

Seeing as the document is fairly long I still think it would be a great idea to create a side bar with an index all with various anchor links pointing near each of your <h3> headings.

The HTML5 way is to make "chapters" around each <h3> heading and it's subsequent content with the <section></section> tags and set id="whatever." Then in the "index" (which I would use the <aside></aside> with appropriate CSS, but it can be on top as well) make an anchor tag with <a href="#whatever" >whatever</a>. HTML5 would also have you put the whole article in <article></article> tags. All this extra markup is for the sake of screen readers and google (who really uses anything else willingly?) to know that this is a section of related text.

[Ferdy]

Regarding variants.

Code: Select all

variant VARIANT
Optionally sent to the engine immediately after 'new' for games that use other than FIDE rules. Sets the engine to play mentioned variant, starting in the initial position for it. The engine stays playing for the side that does not have the move, but should not start pondering on this position. Only used with VARIANTs that the engine announced it could play in the 'feature variants="VARIANT1,VARIANT2,..."' command at startup. Note that it is only implied an engine plays variant normal if it did send feature commands, but not a variants feature. Otherwise 'normal' must be listed amongst the variants. If VARIANT is not an XBoard standard variant (see appendix B), the engine shout reply with a "setup" and possibly "piece" commands to define it:

I can't understand clearly what you mean by the following. Would you explain it further?

Code: Select all

Note that it is only implied an engine plays variant normal if it did send feature commands, but not a variants feature. Otherwise 'normal' must be listed amongst the variants.

[Sven]

Regarding variants.

Code: Select all

variant VARIANT
Optionally sent to the engine immediately after 'new' for games that use other than FIDE rules. Sets the engine to play mentioned variant, starting in the initial position for it. The engine stays playing for the side that does not have the move, but should not start pondering on this position. Only used with VARIANTs that the engine announced it could play in the 'feature variants="VARIANT1,VARIANT2,..."' command at startup. Note that it is only implied an engine plays variant normal if it did send feature commands, but not a variants feature. Otherwise 'normal' must be listed amongst the variants. If VARIANT is not an XBoard standard variant (see appendix B), the engine shout reply with a "setup" and possibly "piece" commands to define it:

I can't understand clearly what you mean by the following. Would you explain it further?

Code: Select all

Note that it is only implied an engine plays variant normal if it did send feature commands, but not a variants feature. Otherwise 'normal' must be listed amongst the variants.

As I understand it:
If an engine sends "feature variants=..." and does not list "normal" there then the GUI may assume it does not support variant "normal". If an engine sends any "feature" command but no "feature variants=..." then the GUI will assume by default that it supports variant "normal".

[Ferdy]

Regarding variants.

Code: Select all

variant VARIANT
Optionally sent to the engine immediately after 'new' for games that use other than FIDE rules. Sets the engine to play mentioned variant, starting in the initial position for it. The engine stays playing for the side that does not have the move, but should not start pondering on this position. Only used with VARIANTs that the engine announced it could play in the 'feature variants="VARIANT1,VARIANT2,..."' command at startup. Note that it is only implied an engine plays variant normal if it did send feature commands, but not a variants feature. Otherwise 'normal' must be listed amongst the variants. If VARIANT is not an XBoard standard variant (see appendix B), the engine shout reply with a "setup" and possibly "piece" commands to define it:

I can't understand clearly what you mean by the following. Would you explain it further?

Code: Select all

Note that it is only implied an engine plays variant normal if it did send feature commands, but not a variants feature. Otherwise 'normal' must be listed amongst the variants.

As I understand it:
If an engine sends "feature variants=..." and does not list "normal" there then the GUI may assume it does not support variant "normal". If an engine sends any "feature" command but no "feature variants=..." then the GUI will assume by default that it supports variant "normal".

Thanks, that I can understand.

[hgm]

Perhaps I should re-formulate that. It would have been simpler to just say the default of the variants feature for v2 engines is "normal". Except that there seems to be a wide-spread misunderstanding that "normal" need not be mentioned (perhaps because many people believe that FIDE Chess isn't a variant, but the "real thing"), so that when they add FRC support to their engine they only add variants="fischerandom" where they did not emit a variants feature before, so that the point needs to be stressed.

And I see now that XBoard actually implements it differently: the default variants list is a user-configurable option, (namely the same as that requests the actual variant: -variant), and it is the default value of the option that is "normal". This to allow v1 engines, which cannot emit a variants feature, to play variants, as they would be automatically assumed to play what the user requests on the XBoard command line.

So perhaps it would be better to just say:

"
Note that not mentioning "normal" in the variant list implies the engine is not capable of playing orthodox Chess. The GUI determines what the default value of the variants feature will be; this should be "normal" unless the GUI is not designed for Chess or the user reconfigured it to suit the engine.
"

[Evert]

Off-topic @Evert: did you see the PM I sent you?

I did not! For some reason the link said "you have no new messages" when in fact I had one. Odd.

I'll try to find a moment to test the variant description with the current version; it looks like it should work correctly.