[Portland] DAPI ideas

[Kevin Krammer]

On Sunday 19 November 2006 23:08, Celso Pinto wrote:
> Hi Waldo,
>
> Bastian, Waldo wrote:
> > I was planning to do an IRC meeting later this week to discuss plans for
> > moving ahead with DAPI. Your notes are a good start for that discussion.
>
> is it a closed meeting? I'd be interested to attend, even if only as an
> observer, if timezone differences allow.

Since this is an open project it is quite unlikely that the IRC meeting would 
be closed :)

> > As far as your broker idea goes, DBUS already provides automatic service
> > activation, configuration of services may still require some more
> > thought though. Currently DBUS has the following features that relate to
> > your broker idea:
>
> (snipped)
>
> I understand your concerns so I'd like to explain myself better: the
> idea is that multiple applications (each with it's own activation
> interface) can provide a distinct service, like the mentioned
> DesktopBookmarkService.
>
> Maybe the bookmarks service wasn't the best example, but with an
> AddressBook service things get more clear I think. There are quite a few
> applications on the desktop that provide each own address books like
> Thunderbird, KContacts, Evolution, etc. Each one of these registered
> itself as a provider of the AddressBook service but only one is the
> default.

I actually think that this is a good example why we don't want it :)

Ideal solution: there is just one address book provider for all desktop 
environments[1].

Likely solution: each desktop environment has its own address book provider, 
however "foreign" applications are supposed to use it when running in this 
environment, so that they access the same data as the "native" apps.

> This way, only the broker has to know which application should be
> activated when a message comes through the bus and it knows this by
> asking the registry.
>
> Also, the broker is a background process that should always be running
> so client application developers do not need to go through the steps of
> checking if a given DBUS service is running and if not, asking DBUS to
> activate it. Just ask the broker to execute something, whether or not an
> application will be started is not a concern.

I somewhat agree on this part. My understanding of DAPI always includes a DAPI 
daemon, which can either implement all services itself or know to which 
process to delegate.

However I see it more like a kind of factory, i.e. while it will likely be 
started by the desktop session, it will always create the service appropriate 
for this session. It can still be configurable through the desktop 
environments tools, but it does not require some kind of registration API.

This is of course for my understanding of the scope of DAPI, i.e. provide 
access to the desktop environments infrastructure in a common way.

Your proposal, as far as I understand, has a bigger scope, i.e. creating a new 
desktop infrastructure or at least its interfaces and implement it in the 
desktop environments or replace their current services[2].

Its a bit like the difference between the Portland initiative and the general 
freedesktop.org project:
- FDO works on how things *should* be done and then each participating 
organisation implements it whenever their release plans allow it. 
Specifications only become standards when they are finally implemented in at 
least the two main desktop projects.

- Portland tries to evalute what is already possible right now and presents a 
new, unified way to access it. Also taking into account that "enterprise" 
distributions release older versions than bleeding edge and have longer 
release cycles.

Obviously any progress within the general FDO project tremendously helps 
Portland, but sometimes it will be necessary to leave state-of-the-art 
designs to FDO and implement simpler designs on already existing 
infrastructure for Portland's goals.

Cheers,
Kevin

[1] actually it might happen. As far as I know there has been interest by the 
developers of the evolution data server (GNOME's current PIM storage) to look 
into using the Akonadi PIM storage.
Since both EDS and Akonadi do a lot more than just addresses, it makes sense, 
IMHO, to have a separate, simplified, address book API in DAPI, also for 
potential implementation of DAPI services on KDE3 infrastructure.

[2] the desktop projects already use services for some aspects and/or are 
planning to increasingly use this concept. For example KDE (I don't know 
enought about the others to comment on them) uses a central daemon (kded) for 
things like hardware integration, password storage, cookies and additional 
daemons for starting applications (klauncherd) and notification (knotify). 
Stretching it a bit KIO slaves are also "data transportation services"
See also [1]

-- 
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/portland/attachments/20061120/c3cab673/attachment.pgp