URN handling, KURL, KURI, KURN

[Rafał Rzepecki]

I'm developing some extensions for Kontact to allow crosslinking objects 
between its components. During development I've faced a need to design an URI 
scheme to express these links, such as references to incidences or e-mail 
messages.

After extensive reading of the associated RFCs, I came to the conclusion that 
URNs are much better suited for the purpose than URLs, as the references 
wouldn't express the location of the individual items, but rather serve to 
uniquely identify them, thus giving them a name.

Alas, I've found that the KURL class doesn't correctly handle URNs. I've 
resorted to a crude workaround of calling KURL::decodeString() when handling 
the URNs to correct the quoting; this isn't ideal, but enough (for now) for 
my purposes.

I've filed a bug for this perceived deficiency in KURL: as KURL doesn't only 
handle URLs, despite its name, but also an assorted variety of other URI 
schemes, I thought that URN should also be introduced there. <bug:110147>

Thiago pointed me to an earlier thread regarding this issue 
<http://lists.kde.org/?t=111076322400001>, which I'd like to relate to. 
I also hope to revive active discussion on the subject.

I agree that KURL class, with functionality built over during the years, has 
become a bloated, all-in-one, not-really-what-it-was-meant-to mess. I feel 
that a major cleanup of this area, in particular drawing clear boundaries of 
what this class (or its equivalent(s)) does and does not, is neccessary for 
KDE 4. I feel that all developers would benefit from a set of classes 
implementing URI-related RFCs to the letter (with particular exceptions for 
non-conformant, yet popular, schemes, such as ed2k:).

I see that URNs will become important in many technologies ahead, if only 
because they are in their rationale more suited to refer to the object's 
names, rather than location, than using whatever 
k<name-your-app-here>:<some-data> schemes developers come up with.

In the meanwhile, I'd be happy to see URN support integrated into KDE 3.5, 
preferably into the KURL itself, as it would make it easier to make urn: URIs 
handled correctly desktop-wise. (For example, with my application, I'd like 
to have a handler that could open incidence references from konqueror and, 
more importantly, any other application (this would be useful in many places, 
think Basket).) I don't think it's likely to break anything.

Another thing, I think a desktop-wide way to describe different handlers for 
different urn: namespaces, as many of these namespaces provide dispatch and 
resolution mechanisms to map them to the URLs or the actual objects. This 
could be done in the existing framework, by introducing a universal handler 
for the urn: scheme and having it dispatch appropriately, based on its own 
set of .desktop files. I am working on such limited solution right now, in an 
effort of enabling usage of my kontact references despite current 
limitations.
-- 
Rafał Rzepecki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050807/b0e07f83/attachment.sig>