Portland/DAPI IRC meeting

We had an IRC meeting about Portland's DAPI today and while most people seemed to have joined to discuss API related things, it more or less turned into a session to clarify positioning in relation with other projects cleaning up some misconceptions.

Lets quote from the log

<thiago> I'm going to be bold and just say my opinion.
<thiago> the way I see it, DAPI has a three-fold purpose:
<thiago> 1) define D-Bus interfaces -- that is, XML files with documentation, pure and simple
<thiago> 2) implement a library that wraps around libdbus-1 and makes those calls in an easy fashion
<thiago> 3) implement a daemon that handles the receiving side of the calls for desktops that don't provide such an interface by themselves
<thiago> s/interface/service/ on the last line
<thiago> I suppose that almost no one will agree with me here. So, what are your opinions?
<krake> No, I agree

As I wrote on IRC, I fully agree!

Points #1 and #3 required some additional discussions later on:


Currently there is only one single file, covering all available methods of DAPI at this point.

However, this is merely a result of converting the already existing API spec to D-Bus, for showing that D-Bus is a viable option for our IPC needs.

The goal is of course to have separated files, each covering an aspect of the DAPI tasks, i.e. one for launching (opening files/URLs in the user's preferred application), one for screensaver handling, and so on.


There is no requirement for an additional DAPI daemon if the desktop's infrastructure already implements all DAPI interfaces.

There were a couple of people worried that DAPI would require a "man in the middle" even when all functionality would be available through the environments already running processes.

After some discussion we arrived at the conclusion that a DAPI daemon would only complement desktop provided functionality, for example when the runtime infrastructure cannot provide D-Bus access.

Project's position towards others (e.g.

A couple of people were afraid that Portland would be competing with the general work.

As written above, part of the DAPI work is specifying D-Bus interfaces and, since D-Bus is now also available for KDE, work has also included such kind of specifications, i.e. agreeing on a set of D-Bus methods to do certain things.

While this looks like competing efforts, it is more an overlapping.

Any relevant specification, which can be suitably implemented with the already released functionality (e.g. KDE3.5), won't require a separate or duplicated DAPI specification.

As an example, controlling the screensaver looks like a good candidate of an official specification which can be used verbatim by DAPI.

Only if a specification is to hard or impossible to implement on older desktops, then there will be a need for Portland to create its own specification.

Additionally, if there is no suitable specification yet, a specification suiting DAPI's needs might be useful as a test bed for a shared specification for not yet released desktop software, i.e. a future specification.


does what you suggest mean that you would like to see a set of standard dbus interfaces, where each interface can be implemented by an application from any desktop environment?

which will be nice for apps like:
- screensaver (as mentioned)
- wallet service
- desktop lock mechanism
- notifications handler
- system tray
- (please comment with more)

just a set of set of standard dbus interfaces that applications can implement by minimum. then apps need to register somewhere that they are implementing a certain interface, so other apps can know their 'dbus name' and a way to execute them. in case there is more than one app registered the --user specifiable-- default is used.

do rephrase correctly what you guys mean?

By cies at Wed, 11/22/2006 - 23:21

However, since DAPI will most likely need to run on older desktop versions as well, it might guarantee only a more limited set of interfaces.

Of course, any restriction that might apply within the scope of DAPI does not imply any restriction on interfaces or covered functionality for current and future desktops.

By krake at Thu, 11/23/2006 - 23:23

does it mean that any DAPI service has to be implemented and up and running as a prerequisite? i surely dont hope so.

example a wallet DAPI; KDE and GNOME both conform their wallet to the DAPI, firefow wants to store a few bits sercurely and first tries to access the wallet DAPI -- if that service is unavailable it will do what every it defaults (or is configured) to do.

having an extensive set of these DAPI's for dbus will be a big pro

By cies at Fri, 11/24/2006 - 12:11

We haven't reached this level yet.

My personal favorite it to have a single guranteed running "factory" service, which can be asked for a specific DAPI service.

If the target service is not running yet, it will lookup the configured default service, start it and tell the caller the D-Bus unique connection name.

If it is running, it will return this name right away.

Since applications can detect when such names become unavailable (application exited), they will likely only have to ask once. Of course, this "lookup" will be hidden when using the convenience lib.

A DAPI implemention on some older desktop, e.g. an implementation for KDE3, might implement all or a lot of functionality within the same process which handles the "lookup" (aka DAPI daemon). The returned connection name would then be the lookup service's own unique name.

I'd like to repeat that any design decision like this does not imply that the same decision is also applicable to any future, e.g. specified, service based desktop infrastructure.

However I hope that it will serve as a kind of incubator

By krake at Fri, 11/24/2006 - 20:57