shared mime info: URI scheme handlers for non browsers

[Rémi Denis-Courmont]

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

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis