Question on service activation

[Havoc Pennington]

Kevin Krammer wrote:
>>> Since a couple of examples suggested that people are using the interface
>>> name and D-Bus name interchangably, we'd rather ask if this was just
>>> concidentally or meant to work this way.
>> The intent is that if you have a global singleton, it has a bus name
>> that identifies it that you use to access it.
> 
> global singleton in the sense that there is only one instance of the process?

And of the object.

An example of a non-singleton: say you have a process that owns 
org.kde.EMail. It might have multiple objects that implement the 
org.kde.EmailMessage interface. Those objects each might have their own 
path, like:
  /org/kde/email-messages/1
  /org/kde/email-messages/2

So conceptually you would do something like:

  EmailMessage proxy = get_proxy("org.kde.EMail",
                          "/org/kde/email-messages/1",
                          "org.kde.EmailMessage");
  proxy.SpellCheck();

You might also have an object that's a singleton within the email 
program. Say for example the MessageSender example I mentioned before.

Since only one process can own the same org.kde.EMail bus name, and you 
have only one /org/kde/message-sender object in this process, then that 
object would be a global singleton (global meaning session-global).

>> I'm not sure I understand what the service broker does in addition,
>> meaning, if you want "the email program" I'd expect that to own the
>> org.kde.EMail or something name, and be accessed using that name.
> 
> Well, the idea is that the calling application knows what kind of 
> functionality it wants to access, so this sounds to me like I already know 
> the interface and am looking for a process implementing it.

You aren't just looking for any and all objects that implement the 
interface though. You're looking for "the" email process, right?

That's what the bus name does. There can be a pile of objects (in a pile 
of processes) that implement a given interface. But only one process can 
own each bus name.

This is more complicated than DCOP; essentially DCOP did not distinguish 
the bus name and the interface. To be honest I could never figure out 
quite how that worked, though, even though many other people felt it was 
simpler ;-) so I was stuck doing it the dbus way.

The way dbus works is just exactly like Java or C++ except there's an 
extra idea of a bus name which is pretty much exactly analogous to a DNS 
hostname or X selection, it's a well-known name you can use to locate a 
process to talk to.

> Which is probably why most activation examples have the same string as 
> interface name and as D-bus connection name, in order to ask for an interface 
> by activating an equal name.

You don't want just any object implementing the interface though, you 
want "the" object. The bus name is the thing that creates the 
uniqueness, just as only one host can have a particular DNS hostname 
(OK, ignoring that the host might be a cluster, etc.)

In other words, I might implement the Flickr API on my servers. Then I 
would have implemented the same interface as flickr.com. But if someone 
wants to upload photos, they will want to talk to flickr.com, not 
havocs-photos.com

If you activated an *interface* you'd get back a list of any server or 
website implementing the same API as flickr. If you activate a bus name 
(analogous to a DNS hostname), then you're asking for "flickr.com" 
specifically.

Hopefully this analogy makes sense...

> Which has the disadvantage that the moment a process acquires this name, it 
> will be defacto the default mail application, no matter what the user has 
> configured.

Right, this is a problem right now, because there is no way for the 
desktop to tell dbus what the user's preference is.

>> What I was saying hasn't been implemented, is that if you have a user
>> setting "preferred email app," we need a way to tell dbus which app to
>> activate to provide org.kde.EMail. I think Thiago's recent proposal
>> tried to address this.
> 
> Yes, I think I read it, the one about AddActivatableService, right?

Yep.

> Example use case: a document creation tool (think word processor) wants to get 
> a contact selection dialog to let the user decide who to send the current 
> document to, then ask the email program to open and prefill a composer 
> window.
> 
> The application does not care which partner applications it is talking to, it 
> just needs to be sure they are the correct ones from the user's point of 
> view.
> It doesn't matter if another application currently running is also capable to 
> do it technically, it might still be the wrong one.
> 
> I am don't like to invent some problem cases, but consider a user having 
> Kontact for calendar, todos, notes but still preferring to use TinyMail for 
> mails.

The way this should work is:
  - there is a spec that defines a bus name and associated objects
    and interfaces for manipulating the contact dialog
  - any app that wants to own that bus name must have the associated
    objects and those objects must implement the interfaces described
    in the spec
  - we have to add some new feature that allows the desktop to
    tell dbus which app to launch when the bus name is requested

You never need to launch the app by *interface* though. There is an API 
contract that goes with the bus name, which includes perhaps a set of 
objects and interfaces implemented by those objects. But this API 
contract is not (in dbus terms) called an interface. Interfaces are 
implemented by objects rather than by processes.

>> The reason this isn't implemented is that nobody has really requested it
>> (let alone volunteered to work on it). I'm not sure myself what the use
>> case of it would be. But there's no prejudice against it, please do
>> bring up any useful features on this list for discussion.
> 
> Hmm. I think I am more or less looking for a way to respect a user's 
> configuration choices and still be available to implement more than one 
> service within one application, without third party applications needing to 
> know ever possible implementations name/path/interfaces.

Third parties will need to rely on some kind of spec that says which 
objects a process owning a given bus name will have, and what interfaces 
those objects will support.

Some of the object paths might be defined in advance and others returned 
dynamically. For example you might predefine an object at 
/org/kde/message_factory, and then that object might have a method 
CreateMessage() that returns the object path of a new message object.
The spec would not need to specify that object path, only that 
CreateMessage() is used to obtain it.

Havoc