This is basically a handshaking process. If the engine wants to use a feature that the protocol defines, it tells the GUI through a feature XXX command. If the GUI does not implement that feature, it notifies the engine through a rejected XXX command.
Ideally the engine should then try to function not using the feature. But typically engine authors typically do not bother to implement more of the protocol than is strictly necessary to run it under their favorite GUI. And as almost any GUI supporting XBoard protocol will support things like san=1 and setboard=1, the prospects that things will work with a GUI that doesn't support it are rather bleak. I can vouch for it that all my engines completely ignre accepted and rejected commands. (As it happens they also don't request san=1, but most of them request setboard=1, and would definitely not work properly if you try to play them from a setup position using the edit command...)
The point is that engine authors don't care a ... if their engine runs on some obscure GUI or not, as just a handfull of GUIs capture 95% of the 'market share', and most of these support the full protocol. Engines therefore typically have quite minimalistic protocol implementation, their author is happy if it runs on these few GUIs. As a GUI author you can only afford a partial implementation if you are similarly interested in just running a handful of engines...
xboard protocol question
Moderator: Ras
-
hgm
- Posts: 28443
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller