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

List:       kde-devel
Subject:    Re: KIO Chains?
From:       David Faure <faure () kde ! org>
Date:       2004-09-08 10:18:46
Message-ID: 200409081218.46740.faure () kde ! org
[Download RAW message or body]

On Wednesday 08 September 2004 12:10, Paul Sprakes wrote:
> On Wednesday 08 Sep 2004 10:06, David Faure wrote:
> > (sorry for breaking the thread, I just subscribed again and saw this post
> > in the archives)
> >
> > > Is it currently possible to define (at runtime) a kio chain? For example,
> > > let's say I create a kio slave which logs every kio request/result and
> > > called it "kiolog". I would then want to create a virtual slave called
> > > "flog" which would basically call "kiolog" followed by "kiofile". The
> > > result would be that any use of the "flog:" protocol would work exactly
> > > the same as "file:" with the addition of keeping a log of every action.
> >
> > It is possible to do this, although it takes a bit of programming:
> > you can call an ioslave from an ioslave, using the normal KIO job API,
> > in order to let the underlying ioslave do all the work.
> > kio_trash (kdebase/kioslave/trash) does this for some commands, using
> > kio_file.
> >
> > A good idea would be to write a generic "relay" ioslave class, which relays
> > every command to another ioslave (the URL conversion between the two
> > protocols would have to be a virtual method). You could then inherit from
> > this generic relay to implement flog:, and Kevin Ottens could inherit from
> > it for his future "filesystems" ioslave (a bit like the current devices:/,
> > but using such a relay mechanism instead of a redirection).
> 
> I'd thought of something like this, but the problem is it isn't flexible for 
> the users - each new combination of slaves will need to be programmed in. 
> What I have in mind is loads of small slaves that do such things as logging, 
> metadata storage, security, caching and duplicating (for automatic backups or 
> automatically saving an internet radio stream), redirecting, filtering (e.g. 
> obscene content, adblocking), decoding etc. The users/distributors could then 
> make up all sorts of combinations to create new functionality. 
> 
> It would also need a mechanism to overide the default protocol names e.g. 
> redefine "http:" to "adblock:"->"netnanny:"->"http:" so that links on web 
> pages will automatically go through a obscenity filter and an adblocker.
> 
> Another possibility is a spam filter (redefine "pop3:" as "spam:"->"pop3:") 
> this would stop all spam from appearing in kmail but if you wanted to check 
> what has been filtered you could just enter "spam:/" in konqy.

You simply have to develop a (user-configurable) chaining mechanism on top of the relay mechanism :)

The other possibility is to use the current kioslave-chaining feature (with sub-URLs)
but I think this only works with get/put (TransferJob). I could be wrong on that though.

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]