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

List:       kfm-devel
Subject:    Re: RFC: Moving main parts of http/ftp/file slaves into kio
From:       Dawit Alemayehu <adawit () kde ! org>
Date:       2001-09-07 5:45:44
[Download RAW message or body]

Hi Kurt,

On Wednesday 05 September 2001 18:03, Kurt Granroth wrote:
> This is a request for comments on the idea of moving the "core" parts of
> the HTTP, FTP, and file ioslaves into kio itself and having the slaves be
> simple kdemain functions.

I for one do not like this idea because it would make these particular slaves hostage to
every other slave that depends on them. :(  This is simply wrong from my point of view.  
For example, we would not have been able to do the port from SalveBase to TCPSlaveBase 
anywhere near as cleanly as we did for 2.2 release to make .  It would have required more 
work just to accomplish that since other things depend on you.  Infact it would not have
been possible because I changed the parent of the the HTTP ioslave to achieve the above 
port.  I do agree that as much of the common code should be should be moved into a common 
library and we have done some work towards this by factoring out commonly used stuff like 
codecs and ssl related stuff out to higher libraries.  I am sure more case can be made for other 
stuff.  But moving the entire gut of an io-slave into a common library just so that other io-slaves 
can reuse it IMHO is wrong and defeats the idea of creating independent io-slaves to handle new 
protocols.

> History
> -------
> There have been two instances that prompted this.  The first was when I
> started to write a maildir ioslave (not worth it, btw).  I wanted to
> "extend" the file ioslave since most of the functionality is the same. 
> Since all of the file stuff is in the slave and since the file.h either
> wasn't installed at the time (or I missed it), I figured I'd have to use it
> *as* an ioslave. This doesn't work.  ioslaves can't easily use other
> ioslaves internally.
>
> The second instance was an email from somebody who wanted to extend the
> HTTP ioslave for some reason that fails me now.  He ran into the same
> problems as me in that short of cut-and-paste, there was no easy way to use
> or extend the HTTP functionality in another ioslave.

Right, but that is a problem with this particular io-slave that I will defintely work
towards solving for 3.0.  See below....

> Why This Is A Good Thing
> ------------------------
> This will allow developers to extend the base protocols to make more
> complex ioslaves.  It occurs to me that somebody is going to put the WebDAV
> support directly in kio_http... but with this, you could easily get away
> with a kio_webdav slave since it just extends HTTP (right?)

Well we are not going, atleast I am not, put WebDAV directly into kio_http.  What
I have been meaning to do and something I am definitely going to do in the head
branch is to allow make kio_http itself extendible so that it carry out its work in
modules.  For example, there will be a module that deals with caching, another one
that deals with cookies, authentication,. etc... This way it is a simple matter of someone
adding support for WebDAV by creating a module that handles WebDAV requests.  At
least this is my plan and what I have already started implementing a while back.

> Putting the code directly into libkio isn't a idealogical shift either
> since those three (well, file and http at least) protocols are *central* to
> KDE. Very little in KDE works without file and http.

Well to me it is :)  But then again I am probably baised since I primarly work on 
the http io-slave and related stuff...

> Possible Downside
> -----------------
> This would require installing the header files for the slaves.  'file'
> isn't a problem since it's already installed.  The http.h file will just
> have to be cleaned up a bit and tweaked to allow for expansion later
> (private pointers, etc).

Not a good idea to install http.h IMHO.  Perhaps a httpmodule.h that you
can inherit from and implement the pure virtual functions to add more functionality.
Hmm... infact all the other protocols might want to provide such a stub that allows
their functionality either to be extended or share with other io-slave some basic
things...

> Comments?
> ---------
> Currently only KDE applications have (for instance) an HTTP "component" to
> use.  This step would extend this functionality to the other slaves.  I can
> think of only good things and a tiny downside.
>
> Any other thoughts on this?

Well I am not convienced about the need for doing this.

Regards,
Dawit A.

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