[Openicc] Linux CM ideology .. Linux CM proposal

[Richard Hughes]

On 8 February 2011 13:08, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> Am 08.02.11, 12:26 -0000 schrieb Richard Hughes:
>> We're not storing private settings. The fact that my DVI1 panel has
>> profile "GCM - Hewlett Packard - HP LP2480zx - 3CM82200KV
>> (2010-09-08).icc" associated with is is hardly private information.
>
> Thats still private. There are users which do not want other user to change
> their settings. I would not use such a misguided concept in any public
> environment.

It's not writable by all users, that would be stupid.

>> The session preferences are stored in the users home directory, of
>
> Your statements are inconsistent. Can you say how colord stores settings?
> * in /var or
> * in the home directory or * system wide in /var and private settings in the
> home directory
>  which files?

preferences != settings.

Preferences are per-user and designed to be changed by the user in the
session. Settings are a one time operation that not all users will
have authority to change.

>> course. But /var/lib in the FHS is for persistent data specific to the
>> machine. The machine includes the devices attached to it. Take away
>
>>> Hence colord in the current form is not an option at all. Its simply too
>>> complex and momolithic right from the beginning.
>>
>> Can you expand on how you think it's complex? It's actually one of the
>> simplest daemons I think I've even written. Compared to a moderately
>> complex daemon like PackageKit it's 1% of the code size and
>> complexity.
>
> That it relies on PackageKit makes it not bloaded?

Please read what I wrote. colord does not depend on PackageKit, that
would be madness.

> Speed issues are merely a technical detail of the implementation not the
> underlying exchange format format.

If we're exchanging mappings, then single files do make sense. But I
fail to see a use case where I want to exchange low level
device->profile settings information with somebody else. Now, a chain
of settings from document to printer would be a very useful thing, but
this is the kind of thing you generate for a process and ship, rather
than copy from the filesystem unchanged.

> I am pretty sure there are solutions to that problem once a format is found.
> E.g. for a single file DB the modification time attribute.

No, the modification time is not suitable as you can't read it and
then write it in one atomic instruction.

Basically, using the filesystem as a database sucks.

Richard.