shared mime info: URI scheme handlers for non browsers

[Bastien Nocera]

On Mon, 2011-10-31 at 17:56 +0200, Rémi Denis-Courmont wrote:
> Le lundi 31 octobre 2011 17:45:37 Bastien Nocera, vous avez écrit :
> > > > That includes regular web pages so I guess the answer is that no
> > > > media-specific application should ever register for a generic
> > > > protocol.
> > > 
> > > So how do you deal with progressive HTTP streaming? How do you deal with
> > > DASH, Apple Live Streaming, MMSH and you-name-it streaming over HTTP
> > > protocols?
> > 
> > You detect progressive HTTP streaming through mime-type, not URI scheme.
> > You handle HLS through the web browser as well, and detect it using a
> > mime-type, not a URI scheme.
> 
> Sure. Say you have detected that the content is for the audio player, from 
> Content-Type, or from the file extension.
> 
> Now, how do you know whether the audio player supports the URI scheme or not? 
> Without something like KDE has, you will need to assume that it supports every 
> URI schemes from the presence of %U, and none (other than file) otherwise.
> 
> Obviously, this will fail in some cases. So some implementations might instead 
> decide to download the whole file. Unfortunately, this breaks progressive 
> download. Alternatively, they could pipe it (or to provide a virtual file 
> system around it). But in some cases, even that fails as the application needs 
> to do something "special" with the URI, as would indeed be the case for HLS, 
> DASH or MMSH.

There are many more problems with that than just knowing whether the
application supports the protocol (or a subset of the protocol). What
about passing cookie that the website might use for authentication?

In any case, it's not what x-scheme-handler is trying to solve.
 
> > > As far as I am concerned as a maintainer of VLC media player, this
> > > proposal is broken by design.
> > 
> > It's not a proposal, it's already in the spec. And it's not broken by
> > design, it's limited in design.
> > 
> > >  We are going to stick with the KDE
> > > 
> > > X-KDE-Protocols approach, since It Actually Makes Sense(tm) and it seems
> > > to work.
> > 
> > It doesn't replace X-KDE-Protocols.
> 
> I think we have to agree on that.

And I hope you'll still be adding "x-scheme-handler/mms" and the likes
to VLC, because that's what a lot of web browsers will be using to
determine which applications support which of those very specialised
protocols.