Custom URI schemes & KDE

Frans Englich frans.englich at
Sat Jan 7 21:38:16 GMT 2006

On Monday 02 January 2006 15:49, David Faure wrote:
> On Monday 02 January 2006 15:34, Frans Englich wrote:
> > Here's how the discussion can be summed up so far:
> * You make up a policy to solve a problem that doesn't exist

No, I don't see it that way. For example, I don't suggest that we change 
existing URI schemes. Thiago speculates in that direction in this thread -- 
perhaps it is a good idea. The proposed guidelines document contains links to 
useful resources/articles, encourage people to use proper schemes, and give 
developers the possibility to use the tag scheme.

And I don't make stuff up to solve inexistent problems. It solves the problem 
which, as you put it, you "lack context to understand"(the DOMError case in 

The problem is not that you object to a certain URI solution for a specific 
problem(as you do in the KIO examples previously discussed), but that you 
stop those who wants to use the tag scheme in KDE.

What "policy" part of the doc don't you like? That the document gives 
developers the opportunity to use the tag scheme?

> You haven't answered my question: ok, so kmymoney defined *internally* a
> protocol named sql, and you find that dirty. So? Did any actual bug result
> from it, or could have resulted from it? I still lack a description of the
> problem that you're trying to fix.

As per your request for an answer: no, I can't demonstrate any concrete 
problem right now. However, other things than this very moment are relevant, 
it's no secret that this is largely preventive measures. How often does one 
allocate/register a name while having a conflict right now? Isn't the whole 
point of name allocation to avoid /future/ complications? I don't speculate 
whether future complications can occur, I take no risks and just say: use the 
tag scheme.

If you insist, feel free to discard the KMyMoney case and instead tell me how 
to solve the DOMError problem.



More information about the kde-core-devel mailing list