[Openicc] Linux CM ideology .. Linux CM proposal

[Richard Hughes]

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.

> 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 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.

> JSON appears to be accessible by yail, which is small, widely deployed and
> cross platform.

Fedora ships yajl by default for just libvirt.

> XML needs libxml2, which is not as small but widely deployed and cross
> platform.

Fedora ships libxml by default for [tons of stuff]

> 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.

> SQLite is a small library. The data base itself is a chunk of data other
> than the previously mentioned formats. It is widely deployed and cross
> platform.

Fedora ships sqlite by default for [tons of stuff]

--

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.

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.

Hence colord.

Richard.