[Openicc] GSoC 2013 preparations

[Kai-Uwe Behrmann]

Am 19.03.2013 08:22, schrieb 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:

Standards can be changed to make things work for several projects. So 
the OpenICC Configuration format slightly changes and extends over ucmm 
to do exactly that.

> * /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)

basically adressed through the OpenICCDirectoryProposal after your patches

> * 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)

JSON is flexible enough to hold hash values if you like them. But be 
aware that some special CMS on Linux notoriously changes profiles and 
then hashes make less sense.

> * 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)

Which is reportedly not sufficient for Oyranos either. However, that is 
no limit of the JSON format and certainly not on the spec worked on here 
inside the OpenICC group. Btw. Oyranos could workaround Argyll's  EDID 
blob by interpreting but not colord's hash value.

> * 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)

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

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

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

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

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.

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

That comparision is moot. We have several existing CMS'es around. We do 
not need more domination through systems like ColorSync or WCS, 
especially not on Linux/BSD.

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

reads like: *not* intented for *collabration*

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

"read only" is a show stopper

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

Where are your patches to the according specs?

 > ucmm-style file to /etc/xdg/color.jcnf on each change if you think
 > that would be useful and not confusing.

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

kind regards
Kai-Uwe