Guidance in (re)design of sytem using dbus

dwelch91 dwelch91 at gmail.com
Thu Dec 13 15:20:41 PST 2007


Hello,

I am involved with a re-design of HPLIP (hplip.sf.net) to use dbus as its
inter-subsystem communication layer. Presently, HPLIP uses a daemon that
uses sockets and TCP/IP using a custom message protocol. The protocol is
used to communicate device status (events) from clients such as a CUPS
backend (hp:), a CUPS fax backend (hpfax:), a SANE backend (hpaio:), etc. to
a central process that can then allow GUI and command line clients to
retrieve and display this status for the user. Additionally, the mechanism
is used to coordinate the fax subsystem, by allowing the CUPS fax backend
(hpfax:) to communicate with a GUI to get sending info for the fax, generate
coverpages, etc.

One difficulty is that many of the pieces or subsystems involved run as
different users. For example, the CUPS backend (hp:) runs as root or lp
while the display of status occurs in a "toolbox" that a regular user runs.

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.

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?  Would the System bus be the required bus to use? Or, can
processes that are running as different users from the logged on user
communicate on the user's Session bus?

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?

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:)?

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

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

Thank you,

Don
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20071213/5c74b428/attachment.html 


More information about the dbus mailing list