[Openicc] GSoC 2013 preparations

[Kai-Uwe Behrmann]

Am 19.03.2013 09:25, schrieb 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.

Oh my bad. I overlooked that.

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

http://www.oyranos.org/wiki/index.php?title=OpenICC_Configuration_0.1
http://www.freedesktop.org/wiki/OpenIcc/ICC_meta_Tag_for_Monitor_Profiles_1.0

That will be the base for the GSoC project.

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

These problems are to be solved as a implementation detail and not 
related to a given format in this case JSON. Consequently, someone 
writing to the SQlite DB will hit the same problems. A write look on the 
level of the file system could help with that much more efficiently, as 
it is a common problem not specific to a CMS configuration.

As far as I know Argyll and Oyranos, they open the configuration files 
on write in one go. So there are almost never many writers. Atomicity 
suggests there is a concurrenting write load. Is this correct? I can not 
imagine a user to be able to produce that write load. And if that 
becomes likely to happen, then a according API can be introduced to 
solve that problem.

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

Can you provide us with a catalog of needed features?

kind regards
Kai-Uwe