[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: platform independent kdeinit/klauncher (was KDE4's IPC)
From:       David Faure <faure () kde ! org>
Date:       2005-12-27 10:04:26
Message-ID: 200512271104.26269.faure () kde ! org
[Download RAW message or body]

On Monday 26 December 2005 01:57, Thiago Macieira wrote:
> >- is for application starting dcopserver/kdeinit/klauncher really
> >required or is a low level implementation located in kdecore possible ?
> 
> >- is for kioslave process creating dcopserver/kdeinit/klauncher really
> >required or is a low level implementation located in kdecore possible
> >(perhaps using threads) ?
> 
> In theory, both cases can be implemented as library code to be loaded by 
> any application. Therefore, kdeinit and klauncher would just be dedicated 
> applications to running those library functions.

I'm not sure if you two have this in mind, but:
kioslaves must be started by an external process (klauncher) so that they can be
passed from a process to another. E.g. when you type a http address in minicli,
minicli starts a GET, puts it on hold once it knows the mimetype, and then launches
the associated application - which could be konqueror, or an image viewer, or a text
editor, etc. - and that application resumes the downloading (by requesting to kio
the same URL again). The goal is to
1) not use HTTP HEAD to get the mimetype, since it's broken on many servers
2) not do a HTTP GET twice because we are looking at the URL from two processes.

This is why kioslaves must be launched by a separate process, and not
just by forking from the app. KDE_FORK_IOSLAVES breaks the above scenario.

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

[prev in list] [next in list] [prev in thread] [next in thread]