Custom URI schemes & KDE

[Frans Englich]

On Friday 06 January 2006 00:56, Thiago Macieira wrote:
> Frans Englich wrote:
> >* I speak for URI solutions recommended by the URI community,
> >which /impossibly/ can run into problems.
> >
> >* You pick up your crystal ball, starts predicting the future, and run
> > your arguments for why cutting shortcuts won't lead to problems.
> >
> >I don't do the latter, I play safe. Especially in the case of KDE where
> > things change radically from one day to another, and development can't
> > be called very organized nor planned ahead, in my opinion.
>
> Ok, let's see if we can compromise:
>
> We use standard URNs and URIs for internal stuff, between an application
> and its plugins, etc. We'll have to investigate where modifications are
> necessary.
>
> In special, note QUrl is, unlike KURL, a URL class. We need an URI/URN
> class, which will probably be the new KUrl wrapper. (We can go ahead and
> call it KUri).
>
> Finally, let me emphasize this: user-visible and especially user-typed
> protocols should NOT look "weird", despite being recommended or not.

I think this is a valid point. Usability demands does a frontal crash with how 
proper URI protocols looks. So, I added this footnote:

<quote>
However, due to the usability requirements KDE in some cases have, there can 
be circumstances where a “rogue” scheme(such as media://) makes sense. 
Carefully consider(discuss, seek peer review) before going for an invalid URI 
scheme, and if so, ensure technical measures are done to lower the risks of 
complication.
</quote>

(But, I don't really see the guidelines document as a strict rule/policy 
paper, but rather a collection of good, general recommendations, and a 
coordination of XML namespace & tag usages.)

>
> One further note: if we do this, we'll require ALL of our protocols to be
> "standardised" or be moved to a tag. One example is fish://: should we
> keep it, or should we internally map it and, through %u in .desktop
> files, tell applications to load
> tag:kde.org:fish://root@remoteserver/filename ?

I don't know :}, I can't tell about the impact of such changes, or what kind 
of clashes it avoids. It sounds ambitious and "properly", but that doesn't 
say much..

I haven't thought about converting existing URI schemes, partly because I'm 
not familiar with the related code -- I'm not a KIO guy.


Cheers,

		Frans