QUrl in KDE 4

[Frans Englich]

On Thursday 19 May 2005 19:23, Zack Rusin wrote:
> 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. :-)

Sometime back KURL was discussed, and one issue being discussed was whether it 
should be splitted into KURI & KURL in order to handle the more generic type 
URIs; possible for speed reasons.

How does QUrl handle URIs? Is there anything particular to say?

From what I can tell it should be just fine, although APIs looks really ugly 
when a function has as return value KURL/Qurl when it actually is a URI..

How would the performance impact be if QUrl was splitted into QUri and 
Qurl(inheriting QUri)? E.g, constructing time for the two, memory footprint, 
and performance of the various functions of them both.

I wouldn't mind a very light and simple(basically decoding/encoding) QUri 
class, because URIs are becoming more central in software design and there's 
multiple RFCs in development for URI schemes, IMHO. For example, if one wants 
to implement a class with semantics specific for a URI scheme one doesn't 
want to inherit from QUrl(which has irrelevant and exsessive functionality), 
but "QUri".

Also, on the topic of IRIs, QUrl handle that nice, I presume.


Cheers,

		Frans