Custom URI schemes & KDE
Frans Englich
frans.englich at telia.com
Sun Jan 8 16:49:32 GMT 2006
On Sunday 08 January 2006 01:12, Thiago Macieira wrote:
> Frans Englich wrote:
> >Indeed, if one put oneself in that position. But it's not me, because I
> > don't lobby for converting existing KIO slaves or that every ioslave is
> > required to use URN tags.
> >
> >I can provide input on any URI idea involving for example KIO, but I
> > don't see how I am accountable since I haven't suggested anything
> > involving KIO. Or am I confused here?
>
> I fail to see the separation.
>
> If you're not asking for the URN tags to be used in KIO and ioslaves,
> where are they to be used?
One example is in KDOM, where the URIs won't enter KIO. URIs are more than
file identifiers(in my mind: KIO has to do with files/moving data), they can
identify, say, a phone number or a book via an ISBN code. If you write a
modularized XSL application, you'll need a URI(of somekind) for a namespace,
for example.
I can't object to converting ioslaves to valid URI schemes, nor can I suggest
it, because I know too little about the implications. All I say is that
perhaps it would make sense. I would with interest read a discussion about
it.
> If it's just some locator data being used behind the scenes, why is it
> necessary to be an URI/URN/URL at all? Take the sql:// example: URL is
> ill-suited to represent the complexities of an SQL query. Better to
> translate it to something else as a string representation.
Of course there are cases where URIs are poor solutions -- I agree a
declarative language such as SQL is one of them. But whether to use URIs or
not for a certain scenario is another discussion.
btw, I think KMyMoney's "sql://" scheme was intended for identifying database
drivers, not the actual queries(yes, one can discuss whether "sql" was a good
name). Better ask the KMyMoney folks about the details of that.
It looks like things have settled(and my execuses if I've misinterpreted), so
I'll commit the doc to DKO after a couple of days.
Cheers,
Frans
More information about the kde-core-devel
mailing list