[PATCH] URI, URL, FOO, URN
frans.englich at telia.com
Wed Mar 16 15:23:08 GMT 2005
On Wednesday 16 March 2005 13:37, Dawit A. wrote:
> On Wednesday 16 March 2005 07:55, David Faure wrote:
> > On Wednesday 16 March 2005 13:42, Thiago Macieira wrote:
> > > Frans Englich wrote:
> > > >Then I'll commit the class to kdecore/ later today or tomorrow,
> > > > something like that.
> > >
> > > For KDE 4, I'd like to see URN/URI/URL sanitised in proper classes.
> > OK, but not necessarily with KURN in kdelibs, right?
> > I mean, KURL (i.e. URLs+URIs) is a core piece of KDE since everything
> > that can be downloaded or uploaded or listed is a KURL.
> > But KURNs seem related to XML parsing and processing, and the class
> > doesn't seem to be useful by itself. So it should IMHO not be in kdecore,
> > but together with whichever class or library needs it.
> Actually URI is superset of both URLs and URNs, i.e. it encompasses both of
> them. If your parser is properly written on the basis of the URI spec. (RFC
> 2396), then it should be able to handle both URLs and URNs. This was the
> original intention of the KURL parser before it got changed to be too
> specific and everything including the kitchen sink got added to it. But
> then again correctness here is meaningless since as you said KURL is a
> centeral piece of software that affects way too many application in KDE...
Yes, it's tricky. An idea which /sounds/ nice at least, is if it would be
possible to have a very light-weight KURI class optimized for
memory/performance which more or less only was a container with encode/decode
and uriMode. It could then be passed around, and be up-cast to classes(KURN,
KURL) when specific functionality and semantics are needed.
What worries me with the wide KURL -- not KURI -- usage, is it constrains and
locks up. For example, with all new "desktop technologies" humming about for
KDE 4 it perhaps turns out that exactly URNs are needed for those
It's not unlikely that such a refactoring(KURI/KURL/KURN) would be possible
without breaking /source/ compatibility for KURL. The problem, AFAICT, with
going with the all-in-one class approach is the potential bloat, and that it
builds on the assumption that no development will happen: "URLs are
everything we'll ever need". I think time will show one class doesn't scale.
KURL is an URI parser, but then it really should be called KURI. Doing merely
a renaming would lead to unbearable upgrade problems AFAICT. I don't think
the all-in-one approach scales; does KURL::isValid() mean a valid URI, URL,
or URN? It also feels plain wrong to put rare functionality as for example
public-id in such a class. AFAICT, classic oop-design dictates a class
hierarchy. What(if) makes people prefer an all-in-one approach? Performance?
Why not dabble our feets,
More information about the kde-core-devel