PATCH:KURL

[Dawit A.]

On Tuesday 29 April 2003 05:35, David Faure wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday 29 April 2003 05:05, Dawit A. wrote:
> > On Monday 28 April 2003 20:28, David Faure wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > On Tuesday 29 April 2003 02:16, Dawit A. wrote:
> > > > - Due to the above change we need to make KURL consistent in how it
> > > > deals with the file protocol. The changes in both ::url and
> > > > ::prettyURL do exactly that by returning file:/// by default instead
> > > > of file:/.  This way not only are we consistent in how the file
> > > > protocol is supported, but we are also compatible Mozilla and old
> > > > Netscape (I think) which support this legacy behavior from RFC 1738.
> > >
> > > I don't think we want that. We want to _support_ this format, i.e. to
> > > parse it, but we still want to show file:/ URLs by default. From a user
> > > perspective, file:/// is horrifying.
> >
> > I am curious why you think that since all the other browsers do just
> > that.
>
> That's not really an argument in my eyes, on this issue (and I'm not sure
> it's true either - at least I don't recall seeing this in IE).

IE does it in its usual broken and half-assed way. When you type file:/// 
it converts it to C:/. But if you ever retype "file" in the completion box 
you will see file:///c:\ and things like that. I tried this at work today...

> And Konqueror isn't only a browser - I don't see why all file-manager users
> should end up with file://////////////path/////////filename :)

Should that be used as a reason.  If so then it could also be argued that 
Konqueror should not even bother to display file:/ for local URLs.  It should 
simply display the path, no ?  BTW, file://////////////path/////////filename 
is fine too, we can deal with that so long as "path" and "filename" are valid 
names. :)))

> > Anyways, the user can still type file:/
>
> But he won't know he can do so, if everything he sees includes three
> slashes. And it's just too easy to forget one. etc.

huh ? There is nothing the user can do to break this at all.  We accept all 
variants just like Mozilla/Opera does...

> > Oh and there is pending bug report about this, br# 52226. See the 1st
> > item in the last comment.
>
> I'm a bit sick of this file:/// issue. It has been proven several times
> that file:/path is just fine, the RFCs allow for it.

Old RFC is ambiguous at best, RFC 2396 is indifferent to it but indeed allows 
what we do. The question is should we support this for legacy reasons.  There 
are a whole lot of non-kde applications that might not adhere to the new RFC 
one of which is the XDND spec itself.  I guess that has been or is in the 
process of being addressed.  But you get the idea...

> > > Shouldn't isValid() be fixed to work with manually-constructed KURLs
> > > instead? (Disclaimer: I don't know if that's technically possible, I'm
> > > just looking at it from the API point of view).
> >
> > IMHO, no :)  The only way m_bIsMalformed can be set to true is once the
> > parser has successfully parsed the string passed to it and determined
> > that it is indeed a valid URL. Anything else is simply a ruse AFAIC :) 
> > What don't you like about it from the API's point of view ? I made it
> > non-mandatory so as not to break anything, but give those that want to
> > make sure they have a valid url the ability to do so....
>
> It's quite obvious IMHO that having an existing method, isValid(), not do
> its job in some cases, is a bug. Introducing _another_ method to workaround
> that bug is not a fix. You'd still have a method that doesn't work. Fixing
> isValid() to work in all cases, makes validate() unnecessary, at least in
> the public API (isValid() could call validate() if the URL has been changed
> since it was last validated).

That would mean yet another flag, no ?  Otherwise, there is no way one would 
be able to tell why the URL is malformed in the first place. That is only the 
creator of the URL would know whether the URL was constructed manually or 
not. That is without the additional flag.  I most certainly can add the 
addition internal flag and proceed that way...

Regards,
Dawit A.