QUrl in KDE 4

[Zack Rusin]

Hey,

as was pointed out a while ago, one of the reasons QUrl was rewritten 
was that it was supposed to replace KURL in KDE 4.

I wanted to provoke people to voice their concerns/bugs/opinions so that 
we can incorporate them in QUrl and make sure it's perfect for KDE.

We already got some comments from Thiago and others which Andreas 
answered in detail. Below you'll see the questions/comments and 
answers. 

Is there anything else? As Andreas said, if anything needs to be 
changed, it's all open for discussion. :-) 

"
> QUrl cannot:
> - deal with the file part of the URL path (except in Qt3 support mode)

Use QFileInfo on path(). The URI spec does not cover files.

> - convert a hostname back from ACE automatically (fromPunycode is
> never called)

That's a bug; I've made a task of it. Of course QUrl should call 
fromPunycode :-).

> - handle URL-looking non-URLs (example: ed2k://|file|
Ugly_looking[file]name|343928602|00000000000000000000000000000000|/)

QUrl follows the URI specification in this respect. QUrl does the right 
thing in rejecting it. If KUrl accepted this stuff, then that's really 
bad.

> QUrl has a strict parser
>> Apparently, QUrl accepts file:/path URLs (no ///)

I don't understand this. Both file:/path and file:///path are allowed 
according to the spec.

> Docs have to make it clear which methods accept parsed and which
> accept raw inputs. For instance, setAuthority/setHost seem not to
> accept Unicode (non-ACE) form of hostnames.

This is the same bug as before.

> Warning: Verify that the extra folding mandated by IDNA is done! It
> does QUnicodeTables::normalize(labels.at(i),
> QString::NormalizationForm_KC, QChar::Unicode_3_1), but IDNA requires
> more than NFKC. 

If so, then this has changed in the specification. If we do not do 
exaclty what the spec does, then this is a bug.

> KURL can:
> - get/set all parts of the URL: protocol, user, password, host, port,
> path & file, (html) ref, query

Just to make things clear about this point; the URI spec does not cover 
the specification of a file path, and the heuristics in KURL are 
horrible and slow down the parser. QFileInfo has this as its major 
responsibility.

> - manipulate the special query "charset" (called fileEncoding)

This _can_ be added to QUrl, but will probably not be.

> - manipulate the URL by doing chdir (cd)

Use QDir::cdUp().

> - convert non-ASCII hostnames to IDN, including in mailto: URIs

The spec says nothing about what comes after mailto:. So you are free to 
call toPunyCode() and fromPunyCode() when generating mailto urls.

> - handle file names on Windows (i.e., convert drives to URL form)
> (when built on Windows) 

Use QUrl::toLocalFile().

> - deal with "sub-URLs", which are hardcoded. See
> http://bugs.kde.org/show_bug.cgi?id=3D73821=20

Suburls should be are gone in KDE 4, you can talk to David Faure about 
this. We already agreed on this point. Suburls break the URI 
specification, and are practically unused and totally confusing.

Andreas
"

-- 
This email brought to you by the language "C" and the number 2^32