[Openicc] Linux CM ideology .. Linux CM proposal

[Markus Raab]

Hello!

Richard Hughes wrote:
> On 8 February 2011 09:15, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> > Am 08.02.11, 11:48 +1100 schrieb Graeme Gill:
> >> I would actually suggest a much more modest proposal to start, and
> >> that is providing a system wide registry of devices and associated
> >> profiles, and a means to read and write the registry.
>
> If you have a registry that more than one program is accessing, you
> *need* locking. Locking with plain files is neither fun nor reliable
> in my experience.

Elektra 0.8 now supports locking. It is implemented by the resolver plugin 
which can support various locking schemas for different use cases or 
operating systems. For POSIX you can move the files in an atomic way, and if 
this is not safe enough you can additionally have a lockfile as guard.

> > To realise the DB we can base it on:
> > * JSON as use in ArgyllCMS,
> > * XML
>
> I'm not sure using extensible formats makes sense without a
> super-stable document schema, else interoperability is just another
> buzz-word. Also, in my experience, having two running processes
> writing the same or different xml files into the same directory and
> using notifications schemes like inotify leads to some fairly
> hilarious impossible-to-debug races.

Elektra plugins define the schema and the API to access the configuration and 
metadata within those files. It even solves the problem how to find the file 
in a configurable way on any operating system.

> > * Elektra files based data base (DB) as in Oyranos
> > * sqlite as used in colord
>
> I'm guessing if you're using Elektra to manage the DB, then you get
> inter and intra-process locking for free, assuming libelectra is
> threadsafe. Of course, not if you access the files directly and avoid
> the libelektra dep. That's certainly one of the reasons I went with
> sqlite for colord.

You assume correctly, Elektra can be used threadsafe. Sqlite is very likely to 
be much faster and to support much more fine-granular locking schemas. The 
disadvantage, however, is that the sqlite files are not human-readable or 
editable.

> > Elektra file access needs Elektra or alternatively file access on C
> > level. The syntax is very very simple. More and more industry
> > applications deploy it. C and Elektra are cross platform.
>
> Fedora doesn't ship elektra by default. I've got thousands of packages
> on my development machine (2106!) and not one depends on libelektra.
> In fact, in the whole of Fedora (over 22000 packages), only 4 packages
> depend on elektra: oyranos, icc_examin, xcm and cinepaint.

Elektra 0.7 used lot of hard disc space for configuration and did not support 
locking or notification. This situation changed with Elektra 0.8 which is, 
however, not released yet. But it is already finished in the basic 
functionality, see http://www.markus-raab.org/ftp/elektra/thesis.pdf for the 
current situation.

> Okay, maybe using Fedora as the example isn't the most politically
> wise move, but my point is to illustrate that libxml2 and sqlite are
> going to be shipped by default on the CD media in *every*
> distribution. Both have healthy upstream progress and a good record of
> patching security problems. Only the latter gives you inter and
> intra-process locks, as thread safety is going to be come ever more
> important with the increasing number of cores in CPUs going up. From a
> raw performance point of view, it's two order of magnitudes faster to
> mmap a single 20k sqlite .db file than it is to read 200 small XML
> files from the file system.

Exactly, that is the reason why Elektra 0.8 will move away from using hundrets 
of files with a single option each but use ordinary configuration files. 
Other approaches are possible because of the plugins, but not to be expected 
with the first 0.8 release.

> You might say I'm biased, but to me a system-wide sqlite database of
> profiles to device mappings with an optional DBus interface and
> PolicyKit authorisation control makes total sense as an opening move.

If you dont care about readable or editable configuration files, sqlite is a 
very good way to go.

Best regards
Markus