[Openicc] GSoC 2013 preparations

[Richard Hughes]

On 19 March 2013 08:02, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> uses /var/lib/colord/icc)
> basically adressed through the OpenICCDirectoryProposal after your patches

/var/lib/color*d*/icc -- i.e. colord not color. This is needed as the
colord binary is running under a limited user account, typically with
the user 'colord', which requires /var/lib/colord/icc to be owned by
colord:colord to be secure. Hence why I didn't submit it for
inclusion.

> Xorg caches EDID. So colord is just an other cache on top of a cache?

The drm layer caches the EDID. Getting hardware data like the EDID is
also a privileged operation and isn't available to all user accounts.

> all which can be communicated through JSON and some specs on how to
> interprete that configurations.

Sure, it could be done using JSON, but there are no specifications on
how to do it.

>> Using a database means we can read and write just the
>> entry we need atomically.
> DBus is *not remote*. So the NFS argument applies to any CMS configuration,
> be it in SQlite or JSON or the one currently used in Oyranos.

I didn't say DBus is remote, and you've completely ignored all my
other points about atomicity and many-writers.

> That comparision is moot. We have several existing CMS'es around.

Well, from my point of view, only one is installed on millions of
Linux computers worldwide. ArgyllCMS is also on many thousands of
systems, but is mainly used to calibrate devices, and not set up by
default to get and set display profile mapping information at user
login. Since starting colord, I've had exactly 3 emails about colord
not setting values in ucmm.

> reads like: *not* intented for *collabration*

Not at all, although you have to expect I'm not going to switch to a
common standard if it's not going to let me implement all the existing
features in colord.

> "read only" is a show stopper

Then please address the many-write issues and the races I outlined.

> Compared to the GSoC project idea that appears like a workaround not a
> solution.

Yes, it is a complete workaround.

Richard