[Openicc] Linux CM ideology .. Linux CM proposal

[Kai-Uwe Behrmann]

Am 08.02.11, 12:26 -0000 schrieb Richard Hughes:
> On 8 February 2011 11:44, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> But how performs Polkit on windows or osX? I guess its non portable.
>
> No, PolicyKit is very portable. It's already useable on Solaris, and
> the BSDs. Windows integration isn't something I'm personally bothered
> about, as applications should be using the core framework on those
> other operating systems, like ColorSync.

With some detailed knowledge I can say there are many settings, which are 
not available on other OS delivered CM Systems. So this argument is not 
helpful. I would pretty much prefere a system, which makes not assumptions 
on a single platform. User want to run Krita, Inkscape, Gimp and so on on 
a variety of operating systems. Something which only runs on Linux is a 
waste of development time.

>> Hiding the user data base in one single file for all users behind a system
>> daemon is nonsense.
>
> It is? Care to explain why?

You wrote the keys are stored in a directory under /var in a sqlite DB.
Thats the only thing I know about the location of the colord DB.

>> Users do not want other users to look into their privat settings.
>
> 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.

>> We have the file system and home directories. This works fine for remote
>> home directories where a DB in /var is invisible.
>
> 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?

> 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

Thats non related. People can take devices around and attach it on 
different machines e.g. camera files.

> /var/lib on a multihead machine and more will break than just the
> device -> profiles mapping...

Again, thats not related.

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

>> 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.
>
> Least common denominator is not good enough. The session needs to
> *query* things like "give me all the profiles for device $foo" and
> "find all the devices that use profile $bar" which is why we should be
> using a database, rather than searching discrete files on the
> filesystem every time the session asks for data[1].

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

> Richard.
>
> [1] if you're caching the data to do the query, you have to provide an
> IPC for the session to use rather than accessing the files directly
> else very quickly the cache becomes decoherent.

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.

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