platform independent kdeinit/klauncher (was KDE4's IPC)

nf2 nf2 at scheinwelt.at
Wed Dec 28 14:58:28 GMT 2005


David Faure wrote:

>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.
>
>  
>
I think the design of kio-slaves is problematic anyway, because 
IO-slaves are single-threaded and can't handle multiple clients at once. 
Therefore real session management is not possible (i guess that's why 
KIO can not write to zip or tar archives for instance).

To achieve real session management and caching, io-slaves should be 
multi-threaded:

1) Either a single daemon for all protocols,
2) One daemon per protocol or
3) One daemon per remote user at server.

IMHO such shortcomings should be corrected by writing new network 
transparency library (D-VFS, Common-VFS), perhaps before moving to KDE4...

Just my thoughts ;-)

regards
Norbert





More information about the kde-core-devel mailing list