Question on service activation

[Kimmo Hämäläinen]

On Fri, 2007-02-23 at 13:36 +0100, ext Kevin Krammer wrote:
...
> > No, this is the wrong model IMHO. I think that whoever defines the
> > 'standard email client interface' (eg fd.o) should define a bus name,
> > object path(s) and interface(s). A client wishing to send an email
> > should call a standard method/interface on a well known (generic) email
> > bus name on a defined object. Any client wishing to be a default email
> > client should activate that name. There should then be a separate
> > mechanism for defining which app should be activated for that name.

This could be done so that some "default application daemon" registers
the D-Bus name for the default e-mail program, but makes it so that
anyone can take the name from it (the ALLOW_REPLACE flag). When a
message arrives to the D-Bus name, the daemon would start what ever
binary has been configured for the D-Bus name, and the binary would
claim the default e-mail program's D-Bus name (but the binary would not
set the ALLOW_REPLACE flag). When the D-Bus name has been taken, the
daemon would forward the message to the same D-Bus name (which is now
owned by the binary). This way we wouldn't need to complicate D-Bus
daemon anymore, and configuring default applications would not be D-Bus'
job (which is an IPC system).

When the execed binary exits, it would release the D-Bus name and the
default application daemon would re-gain it (isn't this the D-Bus name
queue thing that is implemented?).

But there's at least these drawbacks in this:
- race condition in forwarding the activation message (or is the daemon
re-gaining the D-Bus name if the binary drops it before receiving the
message? Thus, receiving its own message...)
- no security, because anyone could claim the D-Bus name (but only if
the 'anyone' has access to the bus)

In practise, this probably would work well enough, unless there is
something I missed...

BR; Kimmo