Custom URI schemes & KDE
Frans Englich
frans.englich at telia.com
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
KDOM).
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.
Cheers,
Frans
More information about the kde-core-devel
mailing list