Fwd: Guidance in (re)design of sytem using dbus

[Colin Walters]

On Dec 13, 2007 6:20 PM, dwelch91 <dwelch91 at gmail.com> wrote:
> Hello,
>
> I am involved with a re-design of HPLIP (hplip.sf.net) to use dbus as its
> inter-subsystem communication layer.

Makes sense.

> My plan to re-work this system is to create a system tray applet that each
> user can optionally run at startup or manually after startup. This applet
> would use dbus to communicate with each subsystem (CUPS backends, SANE
> backends, I/O, etc) and retain the status for eventual sending to a user
> process such as a toolbox GUI, command line tool, etc.

I think it'd be simpler to have the user session tools all query the
system directly, rather than having a central daemon in the user
session that they all query.  The fewer components in a system that
have state the simpler it is, and most of the state is already in the
system, right?

> Some questions about how to proceed:
>
> 1. If the system tray applet is running as a regular user (and there could
> be multiple copies running in a multiuser scenario), I assume that there is
> some prohibition to communicating with processes that are running as root,
> lp, lpadmin, etc?

I believe by default any user process can monitor signals on the
system bus, but is denied from invoking any methods.  Your software
can poke holes in these restrictions by adding a file in
/etc/dbus-1/system.d.

> Would the System bus be the required bus to use?

Yeah.

> Or, can
> processes that are running as different users from the logged on user
> communicate on the user's Session bus?

No, you can't do this sanely.

> 2. It seems that using a 1:n signal makes the most sense to broadcast status
> updates to all running system tray applets? Each applet would have to have a
> unique bus name?

N user session programs can each pick up a signal from a process on
the system bus.

> 3. I understand that it is possible to have dbus launch processes
> automatically in response to a message. Would it be possible to have the
> system tray applet launch a, for example, a fax send GUI in response to a
> message from the fax CUPS backend (hpfax:)?

I would just have your system tray applet launch the other program
itself in response to that message; or just run the UI in the same
process.  I don't think it's necessary to indirect through the session
bus for this.

> 4. The processes that will be simply sending events to the applet will not
> have to run a dbus mainloop, correct?

Right, you can send dbus messages without a main loop.

> 5. Any other considerations or gotchas I need to be aware of?

None that I can think of; you might take a look at the work that was
done on sending CUPS status messages to user sessions as an example.