Proposal for Linux engine standard

[Michel]

We should not give in before even starting a fight, just out of pessimism.

That is correct and I don't think there actually has to be a fight. The Debian packagers of chess software are only a few people. I am sure they are reasonable.

There are some standards for files on Linux that have to be respected (LSB and more importantly LFS) but otherwise any reasonable proposal is good.

[Don]

I think you will find that this is not space for the entire world to make up whatever standards they see fit. What you and I might like is not necessarily going to fly. In other words you cannot just put anything you want anywhere you want and expect it to be respected.

That is just selling ourselves short. First we must think what satisfies our needs, and make sure it is good and elegant. Then we are in a good position to convince those that have the power to decide about this. Someone must act first. Chess has always had a leading role in the development of AI games, so we would be the natural party to take th initiative.

We should not give in before even starting a fight, just out of pessimism.

I'm not being pessimistic, I'm just being reasonable and logical. If you want to change just this one things (/usr/share/games) then you really have an obligation to reorganize the whole space. There are OTHER games in /usr/share so they need to be moved too, otherwise all you are doing is ad-hoc and out of sync with standard practice.

Also, don't forget that you need to have /usr/share/editors in order to combine them in a logical way and you need to write a position paper explaining that /usr/share should not be used for specific applications like it is now but should be restructured in a more "logical" way.

If you want to do the "right thing" you need to think a little bit farther ahead than you are doing now.

[hgm]

But this is not what I want at all. The only thing I want is to reserve a single name in /usr/share/games, namely /usr/share/games/plugins. Other users of /usr/share, and even /usr/share/games can continue to do exactly as they have always done, or exactly as they want. So would I. Of course I would continue to distribute XBoard with its data files in /usr/share/games/xboard, and Fairy-Max with its data files in /usr/share/games/fairymax, and I would expect others to do the same. I want them to stay OUT of /usr/share/games/plugins, not IN. Except for this one tiny ini file that they could install there to broadcast that they are there, and what exactly they are, so GUIs could benefit from it.

[stegemma]

But this is not what I want at all. The only thing I want is to reserve a single name in /usr/share/games, namely /usr/share/games/plugins. Other users of /usr/share, and even /usr/share/games can continue to do exactly as they have always done, or exactly as they want. So would I. Of course I would continue to distribute XBoard with its data files in /usr/share/games/xboard, and Fairy-Max with its data files in /usr/share/games/fairymax, and I would expect others to do the same. I want them to stay OUT of /usr/share/games/plugins, not IN. Except for this one tiny ini file that they could install there to broadcast that they are there, and what exactly they are, so GUIs could benefit from it.

Maybe other games needs plugins and wants to use the same name. To avoid confusion, maybe its better to use another standard name and a subfolder. I think about this:

/usr/games/board_interfaces/plugins

this could be interesting to expand the standard later, for sample:

/usr/games/board_interfaces/engines

(or simply 'board' instead of 'board_interfaces?)

[Michel]

/usr/share/games/plugins

I am still not happy with this. A chess engine is really something different from a flash plugin (it is not because a chinese chess gui demotes a chess engine to a plugin that it is really the right name....).

Calling the directory "plugins" will lead to a lot of confusion since the word plugin already has a quite specific meaning. Usually a plugin is a shared library which is loaded by an application which exports some functions which the application can call. Plugins are specific for a specific application. They are not generic things like chess engines.

Here is a typical plugin

/usr/lib64/rhythmbox/plugins/visualizer/libvisualizer.so

[hgm]

Maybe other games needs plugins and wants to use the same name.

Well, that is great for them, bcause then it is alrady there and they only have to use it!

To avoid confusion, maybe its better to use another standard name and a subfolder. I think about this:

/usr/games/board_interfaces/plugins

this could be interesting to expand the standard later, for sample:

/usr/games/board_interfaces/engines

(or simply 'board' instead of 'board_interfaces?)

It seems more logical to do it the other way around:

/usr/games/plugins/board_intefaces

Then in the whole subtree there is nothing that doesn't have to do with plugins. Because maybe other games need board_interfaces, and who knows what kind of stuff they will want to store there.

But perhaps we should somehow indicate that it is not meant to store the plugins themselves. something like

/usr/share/games/plugin.profiles/board.games/chess

[Don]

/usr/share/games/plugins

I am still not happy with this. A chess engine is really something different from a flash plugin (it is not because a chinese chess gui demotes a chess engine to a plugin that it is really the right name....).

Calling the directory "plugins" will lead to a lot of confusion since the word plugin already has a quite specific meaning. Usually a plugin is a shared library which is loaded by an application which exports some functions which the application can call. Plugins are specific for a specific application. They are not generic things like chess engines.

Here is a typical plugin

/usr/lib64/rhythmbox/plugins/visualizer/libvisualizer.so

Don't forget what the guide says about this either. It is strictly for data only, and could be mounted as read only.

This is one of those things you don't want to get wrong - it will either be totally rejected or it will end up being a constant nuisance. It's not uncommon for distributions to change things to match their own vision of how things should be done so we would want to minimize the chance of that happening.

In my opinion, even though this is not quite as hierarchical as you might want, a more consistent with common practice way would look something like this:

/usr/share/games/chess/fruit
/usr/share/games/chess/toga

/usr/share/games/shogi/*
/usr/share/games/checkers/*

The pattern is /usr/share/GAME_TYPE/APPLICATION_NAME

I see that the only time a hierarchy is used in /usr/share is for things like fonts - something that is used everywhere in the system by many programs. Otherwise it's very application specific - not even text editors have their own shared Folder and one text editor is much closer to another than various kinds of board games.

games is another exception but games on a computer are ubiquitous and it makes some sense. In general you have to strike the right balance between going crazy with creating sub-directories gratuitously and being reasonable.

On a freshly installed system you home directory will have this in it:

Desktop
Documents
Downloads
Music
Pictures
Video

One could subdivide this in a few different ways. Music, Pictures and Video's could be combined into a single Media Folder for example. Pictures are in some sense documents. I think some people believe that a directory tree should always have just 2 branches and try their hardest to make it so, even if they have to use force. Like trying to make a puzzle piece fit that is close but not quite right.

The general principle here that you should never be less specific than what would confuse people who are looking for something. Imagine a monopoly programmer deciding to create this:

/usr/share/games/board

Then the risk programming doing this:

/usr/share/games/strategy

and we decide to use

/usr/share/games/plugins

Now which of those does our chess stuff go in?

It's just hard for me to believe you don't see the problem. My proposal has no ambiguity at all to it. Under games use /chess, /shogi /whatever and nobody will be confused and GUI software can easily find it.

Admittedly, part of the problem is that in general /usr/share is pretty application specific. So despite what we do, A GUI that needs to install global data is also going to have it's own directory in /usr/share/games so you will see /usr/share/games/Arena (if Arena were ported to Linux and part of a distribution) and so on.

Don

[hgm]

Usually a plugin is a shared library which is loaded by an application which exports some functions which the application can call.

ChessBase engines are shared libraries, right? The SMIRF engine is a DLL. It seems to me the connection method is just a technical matter. Users would not know the difference between a pipe, a socket or a DLL.

I think in general the term 'engine' causes far more confusion. (The already mentioned graphics engines...)

In computing, a plug-in (or plugin) is a set of software components that adds specific abilities to a larger software application.

And somewhat later:

As shown in the figure, the host application provides services which the plug-in can use, including a way for plug-ins to register themselves with the host application and a protocol for the exchange of data with plug-ins. Plug-ins depend on the services provided by the host application and do not usually work by themselves. Conversely, the host application operates independently of the plug-ins, making it possible for end-users to add and update plug-ins dynamically without needing to make changes to the host application.

Sounds like a pretty accurate description of the GUI-engine system to me. (Except that the registration could be done better, which we are working on now.)

Open application programming interfaces (APIs) provide a standard interface, allowing third parties to create plug-ins that interact with the host application. A stable API allows third-party plug-ins to continue to function as the original version changes and to extend the life-cycle of obsolete applications.

Sounds like WinBoard protocol...

[Michel]

In computing, a plug-in (or plugin) is a set of software components that adds specific abilities to a larger software application.

Note that application is used in singular! Plugins are usually meant for a specific applications. They are not generic. Unlike chess engines. Chess engines can even work without any gui unlike a plugin which needs the host application...

But seriously why a confusing term like "plugin" if for example something like "ai_player" _literally_ describes what a chess engine is ...?

[Michel]

Anyway the name of the directory is not really important of course. It is just that I think that plugin is about the least descriptive term of all those that have been discussed