PATCH:KURL

[David Faure]

-----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).
And Konqueror isn't only a browser - I don't see why all file-manager users
should end up with file://////////////path/////////filename :)

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

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

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

- -- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+rkdO72KcVAmwbhARAuNwAKC00KSv8qi8lCQNTOCTMphYM6X8YQCfXT25
hjf/k5JqInry7eRA//wp7ME=
=+oPD
-----END PGP SIGNATURE-----