[colord] Why is colord a daemon?

[Mattias Andrée]

On Mon, 13 Apr 2015 19:59:39 +0100
Richard Hughes <hughsient at gmail.com> wrote:

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

So why not shared memory and read–writelocks?

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

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

> * To be able to access user profiles (via a fd) from
> other system daemons

I think a need an example.

> * Provide a system abstraction of color sensors for
> calibration, which have to be serialized/shared

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?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/colord/attachments/20150413/7489ba91/attachment.sig>