Custom URI schemes & KDE
frans.englich at telia.com
Mon Jan 2 14:34:48 GMT 2006
On Monday 02 January 2006 10:37, David Faure wrote:
> On Saturday 31 December 2005 18:27, Frans Englich wrote:
> > On Friday 30 December 2005 21:50, David Faure wrote:
> > > On Friday 30 December 2005 17:39, Frans Englich wrote:
> > > > An application needs to shuffle data around and -- for internal use
> > > > -- invents a "data" scheme. Then the application grows and the URI
> > > > scheme becomes part of, say, an interface between plugins. Who knows
> > > > what happens, perhaps KIO gains support for the actual data
> > > > scheme(RFC2397) and the mess is there.
> Not really since the app has to filter out "data" urls in the first place,
> since when it was written KIO didn't support it.
> > And the advice "Yeah, just invent a scheme and use your app name" is
> > bound to cause trouble. Right, "kmymoney" has a low /likely/ hood, but
> > what about "kgdb"? And what is the likely hood in X years?
> Doesn't matter. You can have only one binary named kgdb in $KDEDIR/bin.
> So either you're using the current kgdb, or a x-years-in-the-future kgdb;
> and why does it matter if they both (with a different name or prefix) use
> the same URL scheme *internally*?
> > I don't see your point; let's return to the document. I understand that
> > you would invent a URI scheme rather than follow the recommendations done
> > by the W3C & IETF, but is there somekind of trouble if those who not
> > wants to do it the proper way?
> I'm being practical; whatever an app uses internally doesn't matter,
> especially if it filters out known protocols before calling out to KIO - it
> has to anyway, since it wouldn't work otherwise! E.g. konqueror filters out
> exec: from the about page before trying to load an exec: url with kio,
> which wouldn't work.
> You haven't proven that using "sql:" in kmymoney created any actual bug
> either; did it?
Here's how the discussion can be summed up so far:
* 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.
What is wrong with doing it the Right Way? Why do you promote a way which
involves risks(sure, call them small), when one can do it safe?
And I ask what I did previously: what is your point? That those who *do* want
to use the tag scheme should not be allowed to, or that they should not
coordinate their use?
I want to get somewhere: clear objections to why the document should not end
up on DKO, or suggestion on changes.
Because specific KIO examples doesn't interest me much; we can switch to
examples in more XML-hardcore applications. And the DOM 3 Core DOMError
example still stands, btw.
More information about the kde-core-devel