New handling for URI scheme handlers

[Jerome Leclanche]

On Mon, Dec 2, 2013 at 7:57 AM, Bastien Nocera <hadess at hadess.net> wrote:
> On Mon, 2013-12-02 at 07:49 +0000, Jerome Leclanche wrote:
>> On Mon, Dec 2, 2013 at 7:13 AM, Bastien Nocera <hadess at hadess.net> wrote:
>> > On Mon, 2013-12-02 at 00:59 +0100, David Faure wrote:
>> >> (very old mail, but this is bugging me again :)
>> >>
>> >> Context: I believe that associating a webbrowser with x-scheme-handler/http is
>> >> wrong.
>> >>
>> >> 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?
>> >> (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 :)
>> >> 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).
>> >
>> > I wish it worked like that as well, but you've just broken one-time URLs
>> > and tried to open a login page in LibreOffice if you don't share cookie
>> > jars between all the clients.
>>
>> With a middleman client this is a solved issue; it would be identified
>> as a page to take care of in the browser.
>
> Let me know when you have that middle man client implemented :)
>
> I wonder how you'll handover to the dozen of different web browsers,
> read their cookie jars, or get applications with links to use your
> middle man client instead of whatever HTTP library they want to use.
>
> It's a nice idea, but it's just not feasible without a clean slate. I
> think that GNOME's current approach is more pragmatic, especially with
> HTTP's baggage.
>

I think you're confused about the complexity of the task.

All the client does is, for http:
 - Parse the url given to it
 - Identify whether it's potentially a file through its name (get a
filename if there's one)
 - If it is, run a match against the xdg patterns on it
 - If there's any match that is not an app that is associated with
x-scheme-handler/http(s), do HTTP HEAD on the url
 - If the HEAD was successful and returns a mime type in the mime type
db and the mime type is associated with an app, *download* the file
 -> Hand off downloaded file to the associated app
 * If any step fails, hand off to web browser

This could be a simple script, or it could be a more involved download
manager that would integrate with the desktop (a neat system-wide
download bar such and such).

J. Leclanche