Guidance in (re)design of sytem using dbus

[Thiago Macieira]

dwelch91 wrote:
>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?  

No, there should be no problem.

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

Yes, you need to use the System bus, because:

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

You cannot connect to another user's session bus. dbus-daemon enforces a 
matching UID. That includes root.

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

Yes, a simple signal from the privileged service to all system tray 
applets would be enough for status updates. The receivers do not require 
anything special to listen for signals, not even unique bus names. The 
service, however, should have a unique 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:)?

Yes, but only in not-yet-released versions of D-Bus. If you intend on 
supporting currently existing Linux distributions, I recommend you don't 
depend on that feature. Instead, make the privileged service launch it as 
needed.

By privileged service, I mean whatever is started by root during system 
initialisation. It doesn't have to stay running as root if it doesn't 
have to. In fact, if it can drop privileges, it would be much better.

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

Correct. But the "processes that will be simply sending events to the 
applet" is generally the privileged service. That one should be running 
an event loop to receive requests from applets and user programs -- 
like, "give me the printer status".

On the system bus, we generally enforce some extra policy rules, meaning 
that we allow certain messages only to come from some users. If you're 
planning on having an ephemeral process connect to the bus, send a 
message to all listeners and disconnect (which means it doesn't require a 
mainloop), be sure that said process runs under the correct user ID.

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

IIRC, hplip had its GUI written in PyQt. I have no idea how the support 
for D-Bus is in PyQt, but I know that other Qt language bindings like C# 
and Ruby have it. It's notably missing from QtJambi though, but there's 
the Java bindings there. Then again, there's a native Python binding 
there as well.

There are a couple of things I could do to QtDBus to make it even easier 
to bind with, but I have not heard from PyQt developers, so I have no 
idea if they have some difficulty or not. But you can refer them to me if 
they need anything in order to support something for you.

Another suggestion: using libdbus-1 directly will make your life 
considerably more difficult. If you can use a binding, do it.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20071214/5415eefb/attachment.pgp