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

[Nicolas Goutte]

On Wednesday 28 December 2005 15:58, nf2 wrote:
> 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).

The main problem for tar/zip is how to write.

ZIP files old obsolete data, so the removing of the obsolete data could be 
delayed.

For a compressed tar.gz or tar.bz2, you would have to do it immediately.

So probably the result would be slower than using Ark. That is probably the 
main reason why nobody has taken the time to write code for the 
write-support.

And I think that this problem would remain even if one KIO slave at a time is 
guaranteed to access the file.

>
> 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

Yesterday, when writing the emails, I had more thought about a master KIO 
server per protocol handling its own protocol KIO slaves.

> 3) One daemon per remote user at server.

That is perhaps also an useful possibility.

>

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

Well, we are in the middle of devloping for KDE4...

>
> Just my thoughts ;-)
>
> regards
> Norbert

Have a nice day!