New handling for URI scheme handlers

[Bastien Nocera]

On Tue, 2010-10-05 at 20:04 +0200, David Faure wrote:
> On Tuesday 05 October 2010, Thiago Macieira wrote:
> > Em Terça-feira 05 Outubro 2010, às 18:20:10, Aaron J. Seigo escreveu:
> > > On Tuesday, October 5, 2010, Bastien Nocera wrote:
> > > > The attached patch is changes to the shared-mime-info spec to mention
> > > > the use of x-scheme-handler/* mime-types.
> > > > 
> > > > Any comments?
> > > 
> > > i suggested to use the mimetype database in a very similar way for
> > > default applications (default terminal, web browser, etc). this idea was
> > > denied because it was "misusing the mimetype database for non-mimetype
> > > data". if this does indeed become part of the fd.o spec, can we also add
> > > something in there for default apps at the same time that uses it in the
> > > same/similar manner?
> > > 
> > > if consistency reigns and this addition does not achieve consensus
> > > approval, we do have .protocol files in KDE already and it would be nice
> > > (and sensible) to use something that already exists instead of
> > > reinventing new wheels of incompatibility.
> > 
> > KDE would require changes anyway. Two reasons that come to mind already:
> > 
> > 1) KDE 4 moved the files from /usr/share/services to
> > /usr/share/kde4/services to avoid clashing with the KDE 3 settings
> > 
> > 2) the same .protocol files store KIO-related information, like which
> > ioslave to launch for doing data transfers and whether the
> > protocol/implementation supports certain features (server-side moves, hard
> > linking, etc.)
> 
> Yes, it doesn't make sense to try standardizing on our current dual-purpose 
> .protocol files.
> 
> I don't see any reason not to convert telnet.protocol into a 
> ktelnetservice.desktop with Exec=ktelnetservice %u and
> MimeType=x-scheme-handler/telnet. The effort takes less time than to write this 
> mail (ok, almost) and I can't think of a migration issue, since the files are 
> installed together with the code that handles it...
> 
> 
> What annoys me a little bit is just that at mimetype-database-generation time 
> we don't know which x-scheme-handler/* mimetypes are going to exist, it comes 
> from reading the .desktop files, which is usually done later on... This makes 
> the implementation more tricky than just "piggybacking the existing mimetype 
> implementation completely". Or are we requiring the installation of a 
> packages/telnet.xml mimetype definition?

Why would you need a mimetype definition? You actually don't...

> Bastien wrote:
> > For the default web browser, and default e-mail client, you'd use the
> > handlers for the x-scheme-handler/http and x-scheme-handler/mailto
> > mime-types, respectively.
> 
> I really object to x-scheme-handler/http.

I guess that's something that I'd need to look into a bit more. I
believe that, in GNOME, asking for a movie on http to be launched would
just launch the default web browser with this URL, which would then pass
it on to something that handled the data type.

So the decision is made solely with the framework libraries, not with
the application.

>  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.

>  Or 
> at least give the option of either one, like we do in KDE ("open best app for 
> the job" vs "always open web browser"). But as soon as someone installs a x-
> scheme-handler/http app, it will break the "open the best app" possibility. 

No, it wouldn't. The only thing this would change is where the setting
is saved. In GNOME, it wouldn't make an once of difference whether it's
in GConf somewhere, or in the mime-types.

> Well, that's because I'm assuming that we'll all give priority to the scheme-
> based lookup over the mimetype-based lookup, since the primary goal is to 
> handle schemes where mimetypes don't even make sense, like mms:/, feed:/, 
> telnet:/. In KDE we actually quite a number of these: mailto, mms, mmst, mmsu, 
> pnm, rlogin, rtsp, rtspt, rtspu, ssh, telnet, aim, callto, feed, news, magnet, 
> irc.

I think it's a problem with how your framework makes the decision on
which handler to use, rather than the spec changes.

Looking up the mime-type for http://foo.org/bar.avi would still return
video/x-ms-avi, not x-scheme-handler/http. x-scheme-handler/http also
doesn't mean "I can handle http URIs", it would mean "I should be
handling all the http URIs, when the decision is made solely on the
grounds of URI scheme".

I hope this clears it up.

Cheers