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

List:       kde-core-devel
Subject:    Re: [PATCH] URI, URL, FOO, URN
From:       Frans Englich <frans.englich () telia ! com>
Date:       2005-03-16 16:52:56
Message-ID: 200503161652.56457.frans.englich () telia ! com
[Download RAW message or body]

On Wednesday 16 March 2005 12: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.

There is one part related to XML, and that's the publicid stuff(it's about 
getting Public IDs in and out of URNs) which I needed in addition to URN. 
Other than it's just an URI type, not tied to XML.

>
> Frans wrote:
> > The Catalog implementation will live in kdenonbeta/kdom and hence first
> > becomes relevant for KDE 4, so I can live with a temporary solution, such
> > as housing the class there
>
> Yes. I don't see the point of enlarging KDE-3.5's kdecore (if there's going
> to be one) with a class that no 3.5 code is going to use, so kdenonbeta
> looks like a better place for now (/kdom if only kdom plans to use it).

For KDE 4 it's probably going to be moved to kdecore since it's generic 
functionality(URI stuff) and in either way would have been central, public 
API.

What makes me find it interesting to have it in kdecore /pre/ KDE 4, even 
though its only concrete usage is in kdenonbeta, is I think it can be nice to 
offer URN functionality for 3rd parties during the years KDE 3 will still be 
active. In other words, it's good to have it in place, and set the standard 
before more scenarios pop up and it turns out to be useful, people start 
copying it locally, ad-hoc approaches etc. I think it's nice that KDE can 
offer advanced functionality to its API users.

But isn't that bloat, to add unused functionality? URN is not some new hyped 
thing, the KURN implements two RFCs. It's usage or design will not change.

For the oasis stuff I'm fine with whatever of couse, but that is my reasoning 
for aiming at kdecore. I'll drop it in kdenonbeta though, considering David's 
and Thiago's votes.


Cheers,

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