[Portland] Current plan summarized

[Kevin Krammer]

On Wednesday 15 March 2006 16:50, Dan Kegel wrote:
> On 3/15/06, Lubos Lunak <l.lunak at suse.cz> wrote:
> > > > 1) Standardize protocol, socket locations, dapi-daemon
> > > > startup-scripts... 2) Standardize the API of a dynamically linked
> > > > dapi-client library ...
> > >
> > > 3) Standardize on a transport that already has a daemon,
> > > e.g. DBus.  Then we don't need to create a new daemon.
> > > Each additional daemon at startup time costs the user
> > > time and RAM.  We want at all costs to avoid bloating the
> > > OS by slowing down boot or stealing RAM, I think.
> >
> >  Your 3) is the same like 2).  The daemon is not there to provide
> > communication but to provide the functionality.
>
> At this point we're just talking past each other without communicating,
> I'm afraid.

Lubos is right though :)

Current DAPI approach

application --marshalled API call--> DAPI daemon (service implementation)

Your suggestion:

application -- marshalled API call --> DBus  -- marshalled API call --> 
service implementation

Using DBus as the transport actually has one daemon more, the DBus-Daemon.

In both cases DEs can do the service implementation in an extra process, but 
don't have to, e.g. KDE could implement it as another kded module (i.e. 
plugin; kded is the KDE service daemon which is always present in KDE 
sessions)

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/20060315/8e30f193/attachment.pgp