New handling for URI scheme handlers

[Jerome Leclanche]

On Sun, Dec 1, 2013 at 11:59 PM, David Faure <faure at kde.org> wrote:
> (very old mail, but this is bugging me again :)
>
> Context: I believe that associating a webbrowser with x-scheme-handler/http is
> wrong.

I'm lost on context here but Id like to share some thoughts on that subject.
>
> On Wednesday 06 October 2010 00:38:40 Bastien Nocera wrote:
>> David Faure wrote:
>> >  When you click a http URL that
>> > points to an .odt document, you want to launch openoffice, not a
>> > web-browser.
>>
>> If you're already in a web browser, yes, but in this case, the lookup
>> shouldn't be including a scheme handler lookup, just an application that
>> handles that particular mime-type.
>
> But what if you're not in a webbrowser in the first place?
> E.g. in a desktop email application, you click on an HTTP link to a .odt
> document. Should that really start firefox, just so that it can then launch
> openoffice?

In an ideal setup, no, it would start in the appropriate application.
But not every setup is appropriate; the "base case" I believe is fine
as such. File gets downloaded, browser handles the mime type lookup
(through xdg-open in most cases).

This is a really interesting subject to me and it seems like a really,
really old question that will never be properly answered. One of the
issues comes from an expectation: if I open
http://example.com/file.avi, should vlc open it directly since it can
stream by http? Should it be downloaded *first* and then ran? Etc,
we've all been through this.

In the case you're describing of email client -> click -> browser ->
download -> run, the browser acts as a middleman that downloads the
file, figures out the mime type and opens it with the appropriate app.
This is a perfectly fine scenario. But if you want your users to skip
that step, you still need a middleman that will download the file and
get its mime type (forgetting the case of abstracting protocols for a
minute).
It seems to me that what you want is a dispatcher that would associate
itself with x-scheme-handler/whatever-is-supported at a higher
priority than the browser. The dispatcher would be called for all http
links in this case, so it would first figure out whether the http link
is interesting (eg. do a name match on the url), see if it's possibly
a file to download. If it is, do an HTTP HEAD on it (or similar), and
if it's still interesting, download the file and hand it off to the
associated app; otherwise directly hand it off to the next app in the
list of associations with x-scheme-handler/http.
The worst case here would be a file appropriate for the browser with a
weird url (eg. /file.avi) and that wouldn't support HTTP HEAD; three
requests. The more common case would be two requests (HEAD + GET, or
IIRC in KDE's optimized case just a reused GET), and for most urls it
would be seamless.


> (same with any other content application that can handle HTTP urls on its own;
> same with other schemes that apps might support, like FTP).
>
> Note that at this point we have no clue about the mimetype. We can start a
> download and find it out, but the first question is: should we do that, or
> just blindly trust the app that says it wants all URLs with this scheme (http,
> in my example).
>
> Since we don't want this to happen in KDE, I had to write code such as "if KIO
> supports a scheme and an app exists for the mimetype x-scheme-
> handler/<scheme>, then give priority to KIO". (for the special case of http,
> there is actually a user setting for "send all http urls to this particular
> app", but that's not the default setting).
> I don't like it very much though, it feels like a hack :)

Understood. With what I described, there's no need for such hack, just
an app with a higher priority than the others with such an
association.

> But I guess it makes sense, since in KDE we prefer to open HTTP urls by
> mimetype, while IIUC in Gnome you prefer to open them with a single scheme-
> associated application (i.e. webbrowser).
>
> So, it's all fine, I'm just curious about what happens in your case when the
> user isn't in a webbrowser in the first place (and to pick the worst case - if
> it's not running yet, which means a long delay coming from the startup of two
> large applications one after the other).
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE, in particular KDE Frameworks 5
>
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg