Question on service activation

[Kevin Krammer]

On Thursday 22 February 2007 23:43, Havoc Pennington wrote:
> 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.

[snip example]

> 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).

Understood.

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

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.

Right, so far no problem.
The issue is that while from the bus' point of view any application owning the 
name will be "the" email process, from the user's point of view only a very 
specific candidate will be, no matter what the bus "thinks".

Maybe the whole name/interface/path discussion hides the real question:
I want my application to communicate with "the" email service. I don't care 
which application this is, if it is running, who is probably starting it, how 
it decided which one of the candiates it is, *but* I want to be absolutely 
without doubt that my application does not anything stupid from the user's 
point of view, something stupid like talking to an email service the user has 
installed, maybe even running, but not configured to be "the" email service.

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

Ah, no :)
There wasn't a difference between interface and object path, but always 
between bus name (application name, sometimes even with PID) and the 
interface/object.

> 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.)

Right, but see above.

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

It does. I am actually quite confident that I understand D-Bus terminology 
sufficiently enough (being a Qt3 bindings maintainer), but I guess that I 
fail to correctly implement my thoughts in English :)

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

Right.

> > 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
 - we need to make sure nobody else can hijack the name and claim to be the 
application the desktop would have launched.

> 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 "launch an interface" idea was basically as way to convey the idea of 
an "association contract", i.e. to acknowledge that there can be multiple 
implementations of an interface, but only one is the desired one, because the 
user has elevated it above all others.

As an afterthought this wasn't very clever, since it unavoidably triggered 
the "must tell clueless developer about D-Bus concepts. again! *sigh*" 
responses :)

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

Absolutely. Though this is a problem of a later stage, when the application 
has finally established contact with the peer.

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

Right.
In some cases, i.e. when the object is referencing a modal dialog, it might 
even be necessary to have it in a different process.
(unless all toolkits can handle multiple modal dialogs without them 
interfering with each other)

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070223/4e9dcca6/attachment.pgp