PATCH:KURL

[Dawit A.]

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.  
Try it in Mozilla/Opera. Well... Opera seems to revert to file://localhost if 
you simply type file:/ the last I checked.  Anyways, the user can still type 
file:/ or file:// or file://localhost and so on and we will happily convert 
it to the "proper" format. From where I sit it is no different than a user 
typing "kde.org" and the end result becoming "http://kde.org".

Oh and there is pending bug report about this, br# 52226. See the 1st item in 
the last comment.

> > -Added a validate() (better name ?) function to give developers who
> > manually construct a KURL object the chance to make sure what they
> > constructed is a valid URL.
> >
> > Why is this needed ? Because isValid() always returns false on all
> > manually constructed URLs.  Besides, manually constructing URLs, i.e.
> > by-passing the parser, might be convenient, but is one of the surest ways
> > to construct invalid URLs.  This function is intended to insure that will
> > not happen without forcing the developer or changing all the mutator
> > functions to perform parsing whenever they are asked to mutate the
> > current state.
>
> 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....

Regards,
Dawit A.