Proposal for Linux engine standard

[Don]

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.

It's no problem with me personally, but as computer chess experts we may want to consider whether we want to impose standards on everyone outside our fields of expertise. But more importantly, just take a look at what is there and you see a clear pattern for how things are done. If you look inside of /usr/share you won't find anything very general. In my /usr/share there are 339 directories. There could be just a dozen, such as /usr/share/editors, /usr/share/system, /usr/share/GAMES and so on but it doesn't work that way.

For example there are many linux editors available. I see /usr/share/emacs, /usr/share/vim, /usr/share/nano and so on. So although my personal preference would be to lump these together into "/usr/share/editors" as that seems more organized, I believe the right thing to do is to not violate the conventions used by the linux community.

But you will also see /usr/share/fonts and other things that appear to be non-application specific data. These would be fonts that all applications could use. But even these are broken down - because you have "/usr/share/consolefonts" So the standard convention is that things here need to be pretty specific to some single function. On my system /usr/share/fonts has 4 sub-directories called cmap, truetype, type1 and X11.

So the thing to do is to research this a bit. Linux does have a philosophy on where things go and there is probably a guide somewhere. We don't want to force something on people that breaks any conventions and if we tried to do so we could not expect to get cooperation from distribution creators - chances are this would come back on us and we would be expected to fix it.

So it's not a matter of our personal taste, we have to play nice with the rest of the world too.

I'll poke around and see if I can find any published guidelines on this type of thing - but I'll bet that we will be discouraged from using any arbitrary name and location we see fit, try putting your configuration files is /usr/bin and see what happens!

[Michel]

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,

You misunderstand. Installing the engine file is the job of the packager (the one that creates the .deb or the .rpm). Not of the author.

[Don]

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.

I agree. What HG is looking for is a unified way for a GUI to discover what is out there, similar to how applications need to know which fonts are available. But in doing so we need to respect any conventions currently in use.

So how to programs such as IDE's in linux handle different languages? It's a very similar problem. Maybe there are other similar situations we can look at to see how things are done?

It's possible that just putting things in /usr/share/xboard is the way to do this but it's not universal to all GUI's.

Don

[Don]

/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

I found this site:

http://www.pathname.com/fhs/pub/fhs-2.3.html

Here is what is said about the /usr/share/games directory - at the end it mentions "game data" being place under /usr/share/games if it's static and read-only. It sounds like it would be compatible with what HG wants.

/usr/share : Architecture-independent data

Purpose

The /usr/share hierarchy is for all read-only architecture independent data files. [30]

This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted. Note, however, that /usr/share is generally not intended to be shared by different OSes or by different releases of the same OS.

Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose.

Game data stored in /usr/share/games must be purely static data. Any modifiable files, such as score files, game play logs, and so forth, should be placed in /var/games.

[hgm]

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.

I am not talking about 'what we want', but about what is. Fact is that many engines for Linux are available as packages for various distros. E.g. for Ubuntu there is crafty, fruit, stockfish, phalanx, gnuchess, fairymax, hoichess. Polyglot is available as a package. They package everything.

I just want to make the most out of that.

[kbhearn]

IDEs usually just look for the binaries that they support specifically by name since they have standard names and are typically found in the path, and then offer manual configuration options for alternate toolchains. This is sufficient for ease of use for the average user while allowing manual configuration for power users.

This isn't really the case of a board game gui that doesn't know what exactly it might find for engines. On the other hand, i've seldom obtained engines on linux through the package tools, rather i'd usually just download the packages and run them from ~/whatever, so guis really ought not to be too engrained with only detecting engine configurations through these files, it should be straightforward to setup a configuration yourself through the gui since even for the average user downloading an engine binary may be as common as installing one from repository (say someone who wanted to keep up to date with the latest version of an engine - it often takes months before someone updates repositories for lesser used programs).

[zamar]

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?

I think that this problem is very similar to MIME types: /usr/share/mime
Each application can drop there a file to announce itself and e.g. tell which file types it can handle.

/etc is a wrong place. It's generally meant for package specific configuration. What we are trying to do here is cross-package thing.

For the file type, I'd prefer to use clear text format, because it's the most common practice in Linux (e.g. /etc/fstab, /etc/interfaces), but if you plan to do really complex and highly configurable system, then XML is probably better choice.

So I'd still like to stay with the simple:

Name = Super-engine
Game = Chess # Call this 'Family' if you want, but IMO Game is better choice.
Variant = suicide
Protocol = WB
WB.cmd = super-engine -suicide

Create one config file per engine. If engine supports multiple variants, create a file per engine-variant combination

[hgm]

..., so guis really ought not to be too engrained with only detecting engine configurations through these files, it should be straightforward to setup a configuration yourself through the gui ...

Completely agreed. I see this just as an extension of the package mechanism, so that for people that do use it, life becomes as easy a they have the right to expect. Installing a package should really put the software on your system in working order. That includes taking steps that the GUIs can use it without configuration wizzardry on the part of the user, requiring him to study the engine docs to learn how to do it.

Configuring the GUI to use a non-compliantly installed engine by sniping at the binary through a Load Engine dialog should always remain possible. And in XBoard, indeed it is. So that is not the problem.

Create one config file per engine. If engine supports multiple variants, create a file per engine-variant combination

What about multi-protocol engines? Also separate files for each protocol? Or allow things like

Protocol = WB;UCI

Perhaps the protocol could be implied by the engine command, as it seems the engine command will be a mandatory scpecification. If you say "WB.cmd =" that implies WB protocol is supported.

As protocol names could evolve to be anything, parsing would probably easier if we would write something like

command (WB) = super-engine --io-mode xboard --suicide
command (UCI) = super-engine --suicide

which then would imply both UCI and WB protocols are supported (and perhaps that WB is the preferred choice, as it is mentioned first).

[hgm]

Btw, how about /usr/share/games/ai_plugins/ as name for the directory?

[zamar]

What about multi-protocol engines? Also separate files for each protocol? Or allow things like

Protocol = WB;UCI

Perhaps the protocol could be implied by the engine command, as it seems the engine command will be a mandatory scpecification. If you say "WB.cmd =" that implies WB protocol is supported.

As protocol names could evolve to be anything, parsing would probably easier if we would write something like

command (WB) = super-engine --io-mode xboard --suicide
command (UCI) = super-engine --suicide

which then would imply both UCI and WB protocols are supported (and perhaps that WB is the preferred choice, as it is mentioned first).

Yes,

As you said something like:
Protocol = WB, UCI
WB.command = super-engine --io-mode xboard --suicide
UCI.command = super-engine --suicide

By default GUI should use first mentioned protocol (WB) if it supports it.