Question on service activation

[Celso Pinto]

Hi,

On 2/22/07, Kevin Krammer <kevin.krammer at gmx.at> wrote:
> > Right, this is a problem right now, because there is no way for the
> > desktop to tell dbus what the user's preference is.
>
> Right.

For the sake of the discussion I think it's useful if everyone is
aware that what we're trying to create is exactly this missing link.

So that if you have installed, in your system, both Evolution and
Thunderbird, both of these applications could implement the interfaces
org.fd.Email and org.fd.AddressBook.

Upon installation, or whatever, the installers would register the
"activatable" services org.gnome.Evolution and org.mozilla.Thunderbird
as possible providers of the above interfaces. This would be done
against *our own registry* that keeps track of which providers there
are for any given interface, not DBUS because it's already clear that
DBUS doesn't do this (doesn't mean that it can't, I'm just saying that
it doesn't and possibly it's not even the DBUS responsibility to do
so)

The fact that the Evolution and Thunderbird bus names are the same as
the activatable interfaces (i.e. org.gnome.Evolution and
org.mozilla.Thunderbird) and their objects are accessible through the
paths /org/gnome/Evolution or /org/mozilla/Thunderbird is merely a
convention.

So now the user defines that Evolution is the preferred application
for email and contacts management.

When a 3rd party application, let's say OOo, wants to send an email,
it asks the broker for the default provider of the org.fd.Email by
invoking the broker.GetDefaultProvider method. This method returns the
"activatable" service name (which is, _by convention_, the same as the
bus name: org.gnome.Evolution) and the path for the object once it's
accessible (e.g. /org/gnome/Evolution, again a convention).

With this information, OOo can ask DBUS to activate the dbus service
org.gnome.Evolution. If it isn't running it'll be started, otherwise
DBUS returns a result code saying that this service is already
running.
Then OOo will get a reference to the DBUS object, using the
information returned by our registry. In Python it's something along
the lines of obj =
dbus.SessionBus().get_object('org.gnome.Evolution','/org/gnome/Evolution').

But remember, now that we have a reference to the object, what we want
to do is to invoke a method (e.g. ComposeMail) defined by the
org.fd.Email interface.
Thus, we'll have the code: email_app = dbus.Interface(obj,'org.fd.Email').

>From there, OOo will invoke the ComposeMail method.

In pratice it's more simple that it appears to be from this description.

If later the user switches to Thunderbird and makes it the default
provider of the org.fd.Email service (as in a generic desktop service
and not a low level DBUS service), when OOo wants to start the mail
composer it'll start the correct application because the default
provider setting has been changed in our registry and OOo asks our
registry the information it needs to start the default provider.

Cheers,
Celso