Question on service activation

[Kevin Krammer]

On Thursday 22 February 2007 22:37, Havoc Pennington wrote:
> Kevin Krammer wrote:
> >> You can imagine various solutions, obviously, but in general nobody has
> >> yet defined the connection between the default handler choices and dbus
> >> activation.
> >
> > I see. We were basically discussion the design and even the need for a
> > broker to map from a service (interface) to a service provider (D-Bus
> > name)
> >
> > 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?

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

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.

> If you have a well-known bus name like org.kde.EMail that is defined to
> be "the preferred email app," then the spec for that bus name would also
> need to specify which object paths the owner of the name should have,
> and what interfaces those objects would implement. That is, there's an
> API contract associated with the bus name, that should be spelled out in
> the same place the bus name is documented. For example, the spec for
> org.kde.EMail might require that an object /org/kde/mail_sender be
> provided by the process owning org.kde.EMail, and that this object
> implement an interface org.kde.MailSender that defines a method SendMail().

Ok, more or less the same thing just the other way around, with the nice 
addition that there is at most one process ever which can be talked to.

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.
Since I do quite some user support for KDE, I personally don't like this at 
all.

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

> A lookup like "which executables could we launch that would have an
> object that implements a given interface" is not supported by dbus at
> all, but it could be. That is, right now you can't say "which bus names
> have an object implementing org.kde.MailSender in their API contract."
> Right now the information like that is purely a matter of docs, there is
> no database or central typelib repository that has interface
> specifications in it (unlike CORBA, COM, etc.).

This is basically what we were discussing. To allow applications to perform 
common tasks through the user's preferred tools.

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

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/20070222/9cba0633/attachment.pgp