[colord] Why is colord a daemon?

[Richard Hughes]

On 13 April 2015 at 19:38, Mattias Andrée <maandree at member.fsf.org> wrote:
> I have a really hard time understanding why colord is a daemon

That's a good question. The main reasons are really so that we can:

* To provide caching and atomicitiy to clients, so that we can very
quickly say "give me the system AdobeRGB profile" without having to
read every profile and sets of overrides.
* Copy a profile system-wide, so it can be used for all user or at the
GDM screen
* To register user profiles to be used for system-wide devices like printers
* To be able to access user profiles (via a fd) from other system daemons
* Provide a system abstraction of color sensors for calibration, which
have to be serialized/shared

There is a lot of complexity in a shared/multi-user system (e.g.
managing access to devices using seats, SELinux and audit) and I
figured the best way to manage the complexity was to do a small
non-privileged daemon like colord. Other projects like Oyranos don't
have a daemon but have not managed the level of complexity or
integration that colord has, a large part in my opinion due to the
core design choices like library/daemon.

Richard