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

List:       kfm-devel
Subject:    Re: Proxy/Cache configuration in sycoca ?? [ Can we store general settings in database for speed ??
From:       Dawit Alemayehu <adawit () starpower ! net>
Date:       2000-05-23 4:26:11
[Download RAW message or body]

On Tue, 23 May 2000, Waldo Bastian wrote:
> On Mon, 22 May 2000, Dawit Alemayehu wrote:
> > Hello,
> >
> > I am trying fix the issue of the configuration information for proxy and
> > cache mangement are not reflected immediately and require the user to
> > manully restart the http io-slaves.  The only problem of reading this
> > information right from the KProtocolManger::xxx is it looks into the config
> > file each and everytime we call it.  Thus, it is much too slow.  Is there a
> > way to store such information as read only entry using ksycoca so we have a
> > very quick access to it ??
> 
> Yes. The "Right Solution (tm)" is IMO to rename the protocol description 
> files from share/config/XXX.desktop to share/services/XXX.protocols and read 
> them into sycoca. For this kprotocolmanager needs to move from kdecore to kio.

Yep I thought so.  Otherwise the solution is going to be ugly using the
remaining two options :)

> I wanted to do this some time ago but there was this ugly dependency from 
> kurl on kprotocolmanager for nested protocols.

This is the real problem.  KURL does too many things for its own good :))) 
Basically only few apps need such extended functionality.  The main one being
konqueror.  Maybe we just need to grep the sources to see what kind dependecies
there are on the two methods that call KProtocolManager ( hasSubURL() and
upURL() ) and if  these depedencies are a few and not in kdelibs, we can perhaps
move over the methods associated with nested protocols into into a whole new class
that inherits from KURL and is located under kio ??

> I think we should move it anyway and come up with a less broken solution for 
> nested URLs. I will move this stuff later this week, if noone else feels the 
> urge.

Hmmm... IIRC we have already been over this and it seems that for better or
worse these two seems to be inter-woven together.  If you want to keep the same
functionality provided by hasSubURL()/upURL(), I do not see any other way to do
this :(( I mean right now if you add a new protocol, as long as you supply the
new protocol definition file, KURL can immediatly use it !!  Hmmm... hard
problems require very hard solutions :))  But I think creating another KURL
class with the added functionality is not a big deal.  I mean supporting nested
URLs is a very special and specific functionality and since the new extented
class in KIO would inherit from KURL, all the class that depend on can simply
switch and used the enhanced one ??  I have a feeling David is not going to
like this...

Dawit A.
// who just began grepping the sources...

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