[colord] Why is colord a daemon?

[Richard Hughes]

On 13 April 2015 at 20:32, Mattias Andrée <maandree at member.fsf.org> wrote:
> So why not shared memory and read–writelocks?

I don't see how you could engineer a solution using shared memory
*without* a controlling process and some degree of privileged
control...

> Seems like this could be done with regular files.
> Similar to ~/.config and /etc.

It sure could, but that's not the way I did it. You need to overlay
the users settings onto the system settings, which isn't trivial to
do. You need to cope when profiles get ripped from under your feet and
also when new devices get hotplugged, removed or change interface.

>> * To be able to access user profiles (via a fd) from
>> other system daemons
> I think a need an example.

You have a printer profile in /home/hughsie/.icc/color and want to use
it in a CUPS pipeline being run system-wide as the root user.

> I don't see how a daemon helps here. Are you not just
> communicating with another daemon process rather than
> spawning a new process and communicating with it?

Nope. The sensor can only be used by one process at a time, and so we
provide an interface to lock the sensor before returning results.
There are also several ways to get the sensor readings, so we also
abstract all the grotty details.

Going back a bit, is there a problem with colord being a daemon that
you're trying to address? If you tell me your specific use case (e.g.
embedded) I can help optimize things a bit for you. If you're asking
because of Blueshift, I worked with the Redshift maintainer a few
months ago, and I'm sure you could just use the same interfaces to
disable the color correction when doing the manual VCGT ramp changes.

Richard