New handling for URI scheme handlers

[Bastien Nocera]

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.