[PATCH] URI, URL, FOO, URN

[Frans Englich]

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 
framework-like things. 

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,

		Frans