[Openicc] Linux CM ideology .. Linux CM proposal

[Kai-Uwe Behrmann]

Am 08.02.11, 10:16 -0000 schrieb 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

Agreed, a schema should follow.

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

That might become a issue for writing into JSON or XML. However, writing 
will occure very seldom. While reading can be assumed stable. A Elektra 
should be able to complely abstract from such problems.

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

Yail, is one of many libraries for JSON. I see many JSON libraries comming 
with a Linux. Some of them are installed by default, e.g. libjson-glib or 
libqjson.

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

A start to solve the configuration chaos ;-)

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

I do not want to argue about a DBus interface.

But how performs Polkit on windows or osX? I guess its non portable.
Hiding the user data base in one single file for all users behind a system 
daemon is nonsense.
Users do not want other users to look into their privat settings.
We have the file system and home directories. This works fine for remote 
home directories where a DB in /var is invisible.
Hence colord in the current form is not an option at all. Its simply too 
complex and momolithic right from the beginning.

If we want to meet somewhere in respect to user settings, we need to start 
with a least common denominator. JSON seems a good candidate to me.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org