Question on service activation

[Kevin Krammer]

On Thursday 22 February 2007 23:46, Thiago Macieira wrote:
> Kevin Krammer wrote:

> >One of my questions in the original mail was: can an application assume
> >equality between interface name and D-Bus connection name and maybe even
> >equality (apart from the separator) with object path.
>
> No.

Good. I always have been pretty sure that this isn't the case but as I said a 
couple of example have this coincidence so I'd though it would be more save 
to ask instead of just being pretty sure :)

> >Or in the example, can Okular do  the equivalent of
> >dbus-send --dest=pim.EMail /pim/EMail pim.EMail.OpenComposer ...
>
> As long as we standardise that "pim.EMail" is the service name that the
> default email component must take on the bus, yes.

The question has been if just knowing the interface would allow to correctly 
derive name and path. As Havoc and you have shown, it isn't.
Again something I'd rather had asked instead of later finding out that an 
asumption has actually been wrong.

> >The next question is a follow up: what if the process implementing
> > pim.EMail also implements pim.Contacts.
>
> Orthogonal to the discussion. The process could be implementing
> org.freedesktop.DBus too for all we care.

Hmm, well, partially. It is quite likely that this (i.e. a PIM service 
implementing more than one PIM category) will be the case.

> >Ideally the process will end up owning both names, but if one
> > application activated pim.EMail and one activated pim.Contacts, isn't
> > it a race condition between the process registering both names and the
> > bus starting the a second instance of the process?
>
> There is no race condition because there's no locking involved in
> acquiring service names.
>
> Wait... do you mean that app A sent a message to activatable but not
> running service name X, then app B sent a message to activatable but not
> running service Y; then application providing service Y actually
> requested name X too?

No.
A sending message to activatable but not running service name X, B sending 
message to activatable but not running service name Y, and X+Y specified in 
the same .service file (the D-Bus tutorial has such an example)

> User preferences don't apply here. If the user doesn't want application Y
> to be service X, it isn't D-Bus that's going to stop it. The application
> must knowingly not register that service.

Then there is either need to a way to tell an application that it should 
request that name (i.e. it is the user's preferred application), or to have 
some handler (in some of my other mails referred to as broker) which is 
always starting the default implementor for a requested functionality, 
independent of any other application having accidentally or indentionally 
hijacked the well known name.

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/bc092aa1/attachment.pgp