[Openicc] GSoC 2013 preparations

[Graeme Gill]

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

Sure, but if you want a new approach to be voluntarily adopted over
the existing one, you need to sell it, and make it compatible, and
make it easy.

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

I wouldn't expect an ordinary user to make system wide configuration
changes. /usr/local/share is the XDG spec. for an application,
system wide file, and (naturally) you need to be an administrator
to change it.

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

I guess I don't know what you mean. An md5 or profile-id
doesn't contain the definition of the colorspace, and
the definition of the colorspace associated with
a device is what's needed. Adding a level of indirection
at this functional level would add a deal of unnecessary
complexity as far as I can see.

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

Sure. So add them.

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

I'm not following you. If re-requesting is a problem, cache it with
the device. If you need metadata, add it.

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

So add such information.

> * There's no way of specifying to use the system mapping, in
> preference to the user mapping

You'll have to explain (is this config/media mappings ?).
If so, add them.

> * A system daemon can't write files in the users home directory

If it's acting on the users behalf, why can it not ?

> * There's no way of falling back to different profiles when the former
> profile isn't available, for instance in the GDM login screen

Why is this a problem ? Surely you fall back on system config/profiles.

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

So add the needed information.

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

Why ? If there is a performance issue, cache the file.
Only re-read it if it changes. It shouldn't change very
often or quickly (how often is a new device installed, a new profile
installed, or how rapidly can a user change their preferences ?)

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

I don't see how a database is going to fix either of your problems.
sqlite doesn't operate over NFS due to fcntl() being broken. DBus
doesn't operate over a network either. (Thankfully, X11 atoms do!)
What sort of race are you talking about ? Can you give an example ?

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

Right, but this isn't an MSWindows & OS X situation. There are multiple
disparate color management tools. Having a common standard
is one way of getting convergence.

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

I'm suggesting that there is a difference between "being open to ideas"
and a slightly more formal process of "each change to the standard
gets to be discussed before being accepted into the standard".

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

If there is such a library to read and write, then I'm much
more likely to want to adopt it. (I think I'm merely expecting
the same standard from others that I provided with ucmm :-).

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

That's still a possible approach. I'm just not sure yet how
much work is involved, and I need to have a mechanism
for hooking with the system API that may not be there.

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

No, I don't think it's useful.

Graeme.