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

List:       kde-core-devel
Subject:    RE: KProtocolManager
From:       Dawit Alemayehu <adawit () earthlink ! net>
Date:       2000-01-06 18:43:21
[Download RAW message or body]

On Thu, 06 Jan 2000, David Faure wrote:
> > the filter protocols (gzip, bzip2,tar).  For example,
> > file:/home/joe/kdelibs.tgz#tar:/
> > would list the content of the tgz file
> Please, let's start to get things right in this thread. The order has been
> changed (because all operations happen on the nested URL, not the main one.
> To list a tar file, it's currently
> tar:/#file:/home/joe/kdelibs.tar
> For a tar.gz file it's
> tar:/#gzip:/decompress#file:/home/joe/kdelibs.tar.gz
> 
> > file:/home/joe/kdelibs.tgz#tar:/##tar:/
> > would list the content of the tgz file within the tgz file.
> No, you missed the nested tar name. It's :
> tar:/#tar:/nested.tar#file:/home/joe/kdelibs.tar

Right.  Sorry should have read the code more carefully.  BTW,  David it looks to
me like we still do not support multiple nesting of the filter protocols i.e. a
gzip within a gzip file for example ( which IIRC was a problem in kfm ) ??

> > Hence, the double hash marks should only be needed when a filter protocol is
> > embeded in another filter protocol.
> That's too complex a syntax, but I understand your idea behind it.
> The real problem is that with bzip/gzip/... we want to skip that level in
> upUrl(), and not with tar. Perhaps we should use ## for such protocols
> (gzip, bzip) and not for tar ?

Yep.  That is why I qualified my previous statement.  I know I was missing
something which you corrected above - the change of the order in the URL for
nested protocols.  In fact this further shows why we cannot easily remove this
dependency from KURL.

> > Having said this let me explain why I said it was not easy to remove the
> > dependency on KProtocolManager.  KURL uses KProtocoManager in upURL() and
> > hasSubURL() because it does not want to hard code which URL schemes can
> > act as filter protocols or are themselves a filter protocol.  As new protocols are
> > added into $KDEDIR/share/config/protocols KURL can deal with them properly
> > otherwise there is no way it would know about them.  This is counter
> > productive as KURL is supposed to handle any protocol generically.  Hence,
> > IMHO the only we can remove the KProtocolManager dependency is by letting
> > KURL treat every protocol as a possible filter protocol and let the app use 
> > KProtocolManager or some other mechanism to determine whether it really is.
> > This is probably too much work for the apps and too redundant ??  Perhaps
> > someone can think of a middle ground...
>
> KURL::join would be utterly confused if it had to guess # or ## without the
> help of KProtocolManager.

Ahhh... I forgot about that too.  Well that seals it for me.  We cannot really
remove this depdency then.

Regards,
Dawit A.

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