[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: RFC KURL rewite (1st STAGE)
From:       weis <weis () stud ! uni-frankfurt ! de>
Date:       1999-10-09 9:33:33
[Download RAW message or body]

Hi,

while I consider it very useful to fix the shortcomings of
the current KURL, I would strongly suggest NOT to use
QRegExp! It is not very efficient!
The current KURL and QUrl use state machines since they
are much more efficient than this QRegExp.

In KDE and especially konqueror URLs are parsed in masses, so
parsing URLs is a time critical thing.

Bye
Torben


On Sat, 9 Oct 1999, Dawit Alemayehu wrote:

> Hello all,
> 
> In light of the recent KDE II meet, which I could not attend :(,  and all
> the flurry of activities that came from that I would like to throw in what I
> have been doing/hacking to the mix as well.  After all it seems like a good
> time for it.
> 
> As the subject suggests, I am currently re-writing KURL so that it
> complies with RFC 2396 (http://www.faqs.org/rfcs/rfc2396.html). Rather than
> going into unnecessary details I will outline a couple of the current problems in
> KURL
> 
> -  Encoding/decoding is done incorrectly.  URL's have to be first split into
> the appropriate components before they can be safely escaped/unescaped.  Please
> refer to section 2.4.2 in the above RFC for details.
> 
> - As a result of the voluntary escaping (encoding), under come circumstances it
> is difficult to determine the state of the URL ( is it escaped or not ). 
> Moreover, the mutator methods do not check the validity of the supplied string
> before modifying the URL, for example setPath (....) and addPath(...)
> 
> Although the current KURL is much much better than its predecessor,  the above
> two problems have still been carried over to it.  Hence the rewrite.  Below I
> have attached the first result of my rewrite : the parse method in KURL. 
> Please note that this is not a patch form because it is very preliminary. My
> intention on posting it now is so that I can get some feedback and also to
> inform others who might be doing the same thing.  Please NOTE that none of
> this will be commited into CVS until the work is completed and there is
> consesus to adapt it.  If anyone wants a patch for testing let me know, and I
> can post one to the list or mail to you directly.  BTW,  the next update will
> probably be
> 
> Changes
> -  Use of regular expressions for parsing (QRegExp). Also parsing adheres to
>    the so called "greedy algorithm" as described by RFC 2396 section 4.3 to
>    resolve ambiguity.
> -  Parsing according to the 5 major components of URI's as
>    outlined by RFC 2396 ( see attached code )
> - Check for illegal characters.  Though this is currently done on the
>    whole URL at the beginning rather than the individual components.
>    Will change in next iteration.  NOTE this will probably break many local
>    URLs that contain spaces ( illegal char ).
> -  Generous (profuse for some folks) documentation in code :-)
> 
> Regards,
> Dawit A.

[prev in list] [next in list] [prev in thread] [next in thread]