Auto-activation of desktop-specific programs

[Thiago Macieira]

Hello everyone

The discussion on the xdg mailing list has come to the point of asking: 
how does one application talk to a desktop-specific program via D-Bus? 
The example in case is the help-viewer program, a hypothetical 
org.freedesktop.Help.

The use-case is simple: this arbitrary application is running and wants to 
display a help page. It should suffice to make a call into the 
org.freedesktop.Help service with the appropriate object paths and 
interface, calling for a certain file to be displayed. The exact details 
of such call, the format of help files, etc. are all beyond the scope the 
problem at hand.

The problem at hand is simple: how does the desktop associate its own help 
program to the org.freedesktop.Help well-known service name?

There are only two main possibilities:
1) the desktop acquires such a name at startup
or 2) the program is started when needed

In option #1, it means we either have the program running and taking up 
resources (a complete waste), or we have a proxy program holding the 
name. Both options are, IMHO, ugly. We can do better.

For option #2, starting it when needed, we have to ask the question: how 
does the system know which executable to run? Remember that this is a 
desktop-specific program.

Proposals are:
1) Put the .service file in /usr/share/dbus-1/services, with an Exec= that 
is a wrapper program. When that wrapper is run, it detects which desktop 
environment is running and exec()s the actual target program.

2) Put the .service file somewhere else and somehow make that known to 
dbus-daemon. We have two options:

2.a) Make it known at dbus-launch time. We have the $XDG_DATA_DIRS 
variable that was introduced into D-Bus's config for this exact purpose. 
So this option can be used right now. The cons: D-Bus mustn't be started 
before the actual desktop script is run (for instance, dbus-launch would 
be run by startkde). Also, modifying $XDG_DATA_DIRS may affect the menus 
too.

2.b) Make it known at run-time: we'd add a new method to 
org.freedesktop.DBus that would add a new path to be searched 
for .service files. Pros: solves the problem of starting the bus daemon. 
Cons: can those paths ever be removed? Can any program add them?
Imagine the use-case when a program from another desktop accidentally adds 
its own paths.

3) Delegate the starting to a running, helper application. This helper 
application would acquire a well-known service name and would provide the 
daemon with a list of auto-startable service names. It would also have 
one method call that means "start this service name".
Pros: flexible enough to accommodate each desktop's own configuration, 
allows for run-time updating of the list of services startable according 
to each desktop's policies, allows even for run-time changing of the 
desktop, mechanism as well as future needs
Cons: much more complex to implement

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- 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/20061228/867dff55/attachment.pgp