hgm wrote:Indeed, the WB-protocol method for ensuring backward compatibility is to use the feature command. There is no restriction on what an engine could send as feature, if it is something the GUI does not know, it simply rejects it. The engine can use the accept / reject reply to figure out if it is allowed to send stuff to the command (although GUIs are typically quite resistant to receiving garbage from engines).
I don't think it is always constructive to insist on 100% backward compatibility, though. If we want to elevate something that already works in practice with most engines to a new standard, allowing it only to be used after it is enabled by a newly defined feature command (which none of these engines would yet send), would just prevent you from using things that work. Sending intra-game level commands seems to be such a case. If it breaks some engines when a GUI does that, so be it. Then the user should simply not request multi-session TC with these engines.
I got rid of the feature type stuff from DEP.
There is a few problems with such additions. You just complicate things more.
In fact end 90s, start 21th century there wasn't a single document that properly described some things with respect to winboard protocol, let alone protover2. You just ran with a few commands and then in logfile you saw which commands you got in and fixed engine for that.
Somewhere around 2001 or so i still 'fixed' the way how to claim a draw for Diep.
The protocol never was really well described when it was at its reign peak.
Now we have moved to the other side of things. Overdesign of a protocol.
All what you seem to add to it now, from functional viewpoint seen is not very efficient and it overshoots the original goal.