[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 6:04:41
[Download RAW message or body]

On Wed, 05 Jan 2000, Stephan Kulow wrote:
> Kurt Granroth wrote:
> > 
> > Waldo Bastian wrote:
> > > Looking at the BNF in RFC1808, a '#' is not allowed inside the
> > > reference after the first #. So we can use the following scheme for
> > > sub-protocols and differentiate unambigious between valid URLs and URLs
> > > with subprotocols purely based on syntax:
> > >
> > > <URL>##<SUB-URL>
> > >
> > > So "http://host/mirrors.html#tar:/pub/kde" would be a normal URL and
> > > "http://host/mirrors.html##tar:/pub/kde" would be an URL with
> > > sub-protocols.
> > 
> > FWIW, I think this method.  It removes a lot of potential ambiguity
> > while being RFC complient!
> 
> Now we just have to consider people getting used to 1.1 :)
> 
> Greetings, Stephan

IMHO this is wrong.  http://host/mirrors.html##tar:/pub/kde is not needed and
causes more ambiguity.  The distinction should not be at that level.  Let
me explain :

If you have a URL http://www.kde.org/index.html#section10, it means that this
URL is refereing to a specific anchor on that page.  Everyone is familiar with
this. If I then change the URL to

http://www.kde.org/index.html#ftp://ftp.kde.org/pub/index.html#section10.

All it means is ftp://ftp.kde.org/pub/index.html#section10.  It is just that
it is expressed in an absolute form from the point of view of the link at
the index.html file at http site.  So there is no need to have this distinction
at this level.  In fact I believe this will break the parser as it currently
is !  Where the change can possibly be done to clarify the "ambiguity" is the in
the filter protocols (gzip, bzip2,tar).  For example,

file:/home/joe/kdelibs.tgz#tar:/
would list the content of the tgz file

file:/home/joe/kdelibs.tgz#tar:/##tar:/
would list the content of the tgz file within the tgz file.

Hence, the double hash marks should only be needed when a filter protocol is
embeded in another filter protocol.

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

Regards,
Dawit A.

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