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

List:       kfm-devel
Subject:    Re: KURL and RFC 1738,1808,2396 [Was Re: Already Fixed Bugs]
From:       Dawit Alemayehu <adawit () earthlink ! net>
Date:       1999-07-28 13:42:31
[Download RAW message or body]

On Wed, 28 Jul 1999, Waldo Bastian wrote:
> Dawit Alemayehu wrote:
> > 
> > Oooops pressed send by mistake :)
> > On Tue, 27 Jul 1999, Dawit Alemayehu wrote:
> > > On Tue, 27 Jul 1999, Waldo Bastian wrote:
> > [snipped]
> > > > The problem seems to be that KURL is based on RFC1738 and doesn't know
> > > > about RFC1808 or RFC2396.
> > >
> > > Right.  I could have expressed all my blah-blah-blah comments with
> > > one statement.  It does not completely comply with RFC 1808 section 4 and
> > > section 5 of RFC 2396.  I chose the longer route because I did not know how many
> > > folks read these RFC's. :)
> > >
> > > > We should fix KURL to be fully compliant with these RFCs.
> > > Right again.  BTW, RFC 2396 simply merges parts RFC 1738 &
> > > RFC 1808.
> > >
> > >
> > > I'll fix this in the HEAD branch next week.
> > 
> > I might get there first since I was finally got around to compiling KDE2
> > on my slow, slow system.  Don't worry it will be a much cleaner implementation
> > since the KURL in KDE2 has a much more cleaner & elegant design.
> > BTW, I will still continue work on KFilteredURL since there are some things
> > that the RFC's AFAIK do not address but are commonly used today in most
> > browsers.  While the above fix in KURL addresses relative URLs such as
> > "//www.kde.org", things like "linuxtoday.com" and "www.kde.org" are not covered
> > by it.  So I think there will be room for this class somewhere if not in
> > kdelibs/kdecore.  I know at least two programs that will make use of its
> > services ( minicli and kongy )
> 
> Yes. I think such a class would be usefull for cases likes described in
> Appendix F of RFC2396 (Handling user input). All cases of "machine-readable
> URLs" should be handled by the normal KURL class IMHO.

Right. Sorry I was looking at RFC 1808 and  RFC 1738 which do not have anything
regarding user input.  I am going to switch to RFC 2396 and use that instead
from now on.

> Optionally we could make it part of KURL as well, but make it a static
> member function like "KURL extractURLFromUserInput(QString)".
> Perhaps then there is less confusion about which class to use.

Great idea ! I like this. That way people won't be confused and they
will get an added benefit free of charge.  Do you think then that this should
be integrated into the same source/header files as KURL instead of creating a
new one ?

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