Proposal for Linux engine standard

[Michel]

A format where everyting is taken literally upto the end of the line whenever a text string is expected would be much more suitable in that respect.

Perhaps, although I have no difficulty with quoting if it is unambiguous.

When using unquoted strings I think it is important to specify that they cannot contain leading and trailing white space characters.

[Don]

The standard way in Linux is to have a configuration file in the users home directory. For example if my program is called "foo" I might have .foo in my home directory configured however it needs to be configured and this should be standardized for all GUI's.

But this only defines how a program is installed for a user. Unlike Windows, linux is a multi-user system at its very heart. So distributions do not install things in the user directories. In Linux it's common to put global configuration files in /etc - often under a sub-directory in the case that there are multiple files. This is VERY common.

So for a GUI, you might have /etc/myGUI/myGUI.cfg

Note that a user can have his OWN private configuration in his home directory using a dot file (which is hidden from normal directory listings) and can be a directory or a simple configuration file. Typically, the private configuration either adds to the global configuration or completely replaces it.

If you want to standardize this, you might define a generic configuration file that each conforming GUI should honor. e.g.

/home/joe/.generic_chess/
/etc/generic_chess/

In these directories would be any number of individual chess program configuration files. These are not configuration files for the chess engines themselves, they will have their own if they have any at all - these are configuration files that define how the GUI interacts with them and tell them what programs are available for installation.

Whatever is done, you really want to change as little as possible about how software is set up and configured. You don't want to define some elaborate system that is especially convenient for the chess community but not standard unix practice.

I think there is a great need for a btter interaction beteen installing GUIs on Linux and installing engines for those GUIs. Currentlly the burdon of configuring the GUI to use the engine is on the user, who would have to go on instructions provided in the engine docs. This is a very undesirable situation.

What I had in mind is that we would decide upon some standard system directory, like /usr/share/games/engines/, where engines could 'drop' a file during their install to announce their presence, and provide some info about themselves. GUIs could then scan this directory to kno hich engines are on the system, and retrieve the info on how to configure the GUI to use it.

For Chess engines it would obviously be important to kno if the engine is UCI or WB, what command is needed to start up the engine, which game (e.g. Chess variant) it plays, if it plays only one, if it has its own opening book, how it reports the score (white POV or stm POV), what its approximate Elo is, etc. And perhaps if it has special demands for specific GUIs, by recommending some GUI-specific GUI options.

For instance, something like

UCI command = fruit
Game = chess
Book = true
Score POV = stm
XBoard options = -fSAN
SCID options = whatever
...

or

WB command = maxqi
Game = xiangqi
Book = false
Score POV = stm
XBoard options = -fSAN -boardSize 49

Any suggestions?

[hgm]

If you want to standardize this, you might define a generic configuration file that each conforming GUI should honor. e.g.

/home/joe/.generic_chess/
/etc/generic_chess/

In these directories would be any number of individual chess program configuration files. These are not configuration files for the chess engines themselves, they will have their own if they have any at all - these are configuration files that define how the GUI interacts with them and tell them what programs are available for installation.

Well, that is basically exactly what I was proposing, except that I proposed to use the system's default data directory /usr/share/games in stead of /etc. If you see these as configuration files, then indeed /etc would be a more logical place. I would call it /etc/game_engines in that case, as it is not just meant for Chess.

But the major question is what to put in these configuration files, and to a lesser extent, in what format?

Otherwise XBoard is already perfectly compliant with what you describe. It has a master config file /etc/xboard/xboard.conf, and a user file ~/.xboardrc . It srves no point to share these between GUIs, as they mostly contain XBoard-specific settings. Although they also contain a list of engines, it also makes no sense to share this with other GUIs, as the engines go accompanied by GUI options needed for running them (e.g. -fUCI for UCI engines in XBoard), which are also GUI-specific. Furthermore, a user can use several GUIs, without necessarily wanting the same engines installed in both. (E.g. he might use gShogi, and only use XBoard for Chess).

So it is just a matter that each GUI can do its own thing under guidance of the user, but draw on this information to make the user's life easy. (E.g. if a new engine was installed, it could start with a popup "New engine detected: Crafty 23.5 Do you want to import it?". And the use would then only have to press OK to get it installed with all necessary options to cure its non-compliancy and exploit its other peculiarities.)

[ZirconiumX]

/usr/share also seems to be pretty commonly used, but I'm a Mac user, so I'm not hugely familiar to Linux practice.

Matthew:out

[Don]

If you want to standardize this, you might define a generic configuration file that each conforming GUI should honor. e.g.

/home/joe/.generic_chess/
/etc/generic_chess/

In these directories would be any number of individual chess program configuration files. These are not configuration files for the chess engines themselves, they will have their own if they have any at all - these are configuration files that define how the GUI interacts with them and tell them what programs are available for installation.

Well, that is basically exactly what I was proposing, except that I proposed to use the system's default data directory /usr/share/games in stead of /etc. If you see these as configuration files, then indeed /etc would be a more logical place. I would call it /etc/game_engines in that case, as it is not just meant for Chess.

That would be a bad name choice since you are already in /usr/share/games - game_engines is pretty generic and could describe dungeons and dragons, monopoly, charades and football. I think you want to narrow it down a bit. Perhaps board_games or something more specific. Presumably you want anything there that is "chess-like", anything that might conceivable work in xboard, right? So I see no problem using chess in the name and it's understood to mean chess and all of it's many variants.

But the major question is what to put in these configuration files, and to a lesser extent, in what format?

Otherwise XBoard is already perfectly compliant with what you describe. It has a master config file /etc/xboard/xboard.conf, and a user file ~/.xboardrc . It srves no point to share these between GUIs, as they mostly contain XBoard-specific settings. Although they also contain a list of engines, it also makes no sense to share this with other GUIs, as the engines go accompanied by GUI options needed for running them (e.g. -fUCI for UCI engines in XBoard), which are also GUI-specific. Furthermore, a user can use several GUIs, without necessarily wanting the same engines installed in both. (E.g. he might use gShogi, and only use XBoard for Chess).

So it is just a matter that each GUI can do its own thing under guidance of the user, but draw on this information to make the user's life easy. (E.g. if a new engine was installed, it could start with a popup "New engine detected: Crafty 23.5 Do you want to import it?". And the use would then only have to press OK to get it installed with all necessary options to cure its non-compliancy and exploit its other peculiarities.)

[hgm]

Board_games would be good. In /etc the 'games' is not redundant. Another name could be boardgame_plugins.

[Don]

Board_games would be good. In /etc the 'games' is not redundant. Another name could be boardgame_plugins.

But Risk and Monopoly are also board games! But board_games is certainly a big improvements. You could have "chess_variants" but that implies that chess is not included.

[Michel]

I like

game_engines

(or just "engines", if we are already in a directory called games).

We are not discussing the configuration of games but the configuration
of engines capable of playing games (that is replacing a human).

[hgm]

But Risk and Monopoly are also board games!

Well, perhaps I should implement Risk in XBoard, and Daniel could implement it in Nebiyu!

But seriously: If someone would write a GUI that supposrts Risk, and there would be separate engines for it... What would be against these engines posting their profiles in this same directory? XBoard wouldn't mind! It would see Family = Risk, and then reject it.

[lucasart]

But Risk and Monopoly are also board games!

Well, perhaps I should implement Risk in XBoard, and Daniel could implement it in Nebiyu!

But seriously: If someone would write a GUI that supposrts Risk, and there would be separate engines for it... What would be against these engines posting their profiles in this same directory? XBoard wouldn't mind! It would see Family = Risk, and then reject it.

I'm really not convinced that a chess engine should be considered as a program per se. It is not a standalone program.
A chess GUI is a program and you could have packages for it (.deb .rpm etc.)
A chess engine is only an executable file that the user drop wherever he chooses (possibly restricted by his choice of GUI)
Why should we want to standardize the way a chess engine gets "installed" when really there's nothing to install.
Besides, it's a real burden on chess engine programmers to start thinking of how to make packages for all distros to install their engine, where this config file shoud go etc, so we can talk all we want on how to do it, I doubt it will become a reality for that simple reason. And even when you do a .deb file for example, getting it into Debian and Ubuntu repo is a complicated process...
I don't mean to spoil the party here, but just to look at it from a pragmatic point of view.