URN handling, KURL, KURI, KURN
divided.mind at gmail.com
Sun Aug 7 05:58:45 BST 2005
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
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel