Auto-activation of desktop-specific programs

[Thiago Macieira]

I needed some comments on this proposal...

Thiago Macieira wrote:
>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/20070116/6d646e62/attachment.pgp