'Guidance in (re)design of sytem using dbus'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: freedesktop-dbus
Subject: Guidance in (re)design of sytem using dbus
From: dwelch91 <dwelch91 () gmail ! com>
Date: 2007-12-13 23:20:41
Message-ID: 5c9a36e80712131520v170fd0ebjf15c61f7d68ff549 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

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

[Attachment #5 (text/html)]

Hello, I am involved with a re-design of HPLIP (<a \
href="http://hplip.sf.net">hplip.sf.net</a>) 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 &quot;toolbox&quot; 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?&nbsp; 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&#39;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 \

_______________________________________________
dbus mailing list
dbus@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus

[prev in list] [next in list] [prev in thread] [next in thread] 