[Portland] Summarize current plan?

[Kevin Krammer]

On Sunday 12 March 2006 22:53, Jeremy White wrote:

> > DAPI consists of two components: A daemon, and a library (libdapi.la)
> > that links to the application.  The library handles the IPC
> > (socket) communication with the daemon and implements the API.
>
> I have to say that this design freaks me out to some
> extent.  (Now I've browsed the archives, but I'm probably
> still missing some historical background, so forgive me
> if this is just ignorance).
>
> But it seems to me that the daemon approach is required
> in order to solve some hard problems (not sure I know what
> they are; my eyes glazed over as I read the VFS thread,
> but I trust you guys that we need it).  I also see
> that it could be handy from an extensibility standpoint.
>
> But I could write a simple static library to make a menu
> *right now*, and it wouldn't need a deamon or anything
> else; it should work on any XDG compliant window manager.
>
> Note that this is possible because I think the menu-spec
> is a nice spec - simple, sweet, and functional.

The stuff dapi currently implements are the things there are no standards for, 
i.e. where each desktop offers the functionality but differently.

I guess thing there are agreed standards for can be directly implemented in 
the application side library without requiring to go through the daemon.

But good point nevertheless, I am not sure we have that covered yet in our 
current design.

Cheers,
Kevin

-- 
Kevin Krammer <kevin.krammer at gmx.at>
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtcentre.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/portland/attachments/20060312/b14cc5e1/attachment.pgp