[Openicc] GSoC 2013 preparations

[Richard Hughes]

On 19 March 2013 00:33, Graeme Gill <graeme at argyllcms.com> wrote:
> The device<->profile information is not really complicated enough
> to justify calling it a database though

I think it is, see below.

> ucmm has historical precedence over whatever colord does. ..colord is the newcomer...

I don't think it's compulsory to use the first implementation of any
standard if it doesn't work for the service:

* /usr/local/share/color/ isn't writeable by user-software, so you
can't do things like "install user profiles for all users" (colord
uses /var/lib/colord/icc)
* Using the filename isn't a really good way of identifying the ICC
profile if we end up moving the profile somewhere else (colord uses
the profile-id, or falling back to file md5)
* Using the EDID works fine to identify a screen (colord uses the EDID
md5) but we need some kind of other identifier for printers, cameras,
and scanners (colord defines some IDs)
* Using the EDID with no metadata requires clients and applications to
re-request the EDID from the hardware to select the profile. (colord
adds metadata to each device so the client can query easily)
* We don't know if the profile added to the device is automatically
added (e.g. auto-edid, or default .icc profiles specified in a PPD
file) or manually added to override the default. (colord uses the
soft/hard enumerated type on each mapping)
* There's no way of specifying to use the system mapping, in
preference to the user mapping
* A system daemon can't write files in the users home directory
* There's no way of falling back to different profiles when the former
profile isn't available, for instance in the GDM login screen
* There's no way to specify preference over a set of profiles for a
specific device, e.g. where you have a printer with 3 profiles for 3
different paper types

and the biggest problem:

* Being a file format, rather than a database would mean completely
re-reading both files every time a client queries any color management
option, and writing both entire files when writing any preference
option. Reading and writing files is slow, and *really* slow if $HOME
or /usr is on something like NFS. Caching isn't available otherwise
you have to watch the backing file for changes (which isn't available
for NFS) and then update the cache after some kind of delay which is
racey as hell. Using a database means we can read and write just the
entry we need atomically.

> * Is the schema documented somewhere ?

No, it's a private implementation detail just like it is for ColorSync
and WCS. Clients are supposed to change and query using the stable
D-Bus API.

> * Is there a process for making changes to the schema in
>   a collaborative manner (ie. an RFC like process) ?

No, but there's a mailing list and I'm open to ideas.

> * Is there a library built over sqlite and available under a free
>   use license (ie. MIT/BSD) to make it dead easy to read and write the
>   information progromatically ?

No, but I could easily write such a library to *read* the data if
required, providing an API stable view of the database.

>> using Oyranos and colord at the same time is not significant enough
>> for the pain of migrating settings and maintaining backwards
>> compatibility.
>
> The problem is that I feel the same way. ArgyllCMS works fine as it is
> - why should I change anything, especially since the Linux version
> is the least popular ?

Sure, I think ucmm is probably the right solution for ArgyllCMS. I
think in an ideal world (perhaps with my biased definition of ideal :)
ArgyllCMS would query the respective native subsystems, e.g.
ColorSync, WCS and colord and then fall back to ucmm if nothing was
found.

>> Just deciding on something as simple as the primary
>> keys for storage has traditionally been impossible between oyranos and
>> colord and so I think this item should be removed from the wiki.
>
> That's a bit of a show stopper problem then.

Yes, I think so. That said, I'd be open to just *writing* a new
ucmm-style file to /etc/xdg/color.jcnf on each change if you think
that would be useful and not confusing.

Richard.