[colord] Why is colord a daemon?

[Mattias Andrée]

On Mon, 13 Apr 2015 21:14:49 +0100
Richard Hughes <hughsient at gmail.com> wrote:

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

But that could be done in a spawn process.

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

No, I'm asking out of curiosity and potential support and
other software.

But I understand now why you have written it as a daemon.
And I believe it is not necessary but that it could have
made for a simpler solution.

> 
> 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/62a05d00/attachment.sig>