Question on service activation

[Havoc Pennington]

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.

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.

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

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.

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

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.

Havoc