shared mime info: URI scheme handlers for non browsers

[Bastien Nocera]

On Tue, 2011-10-18 at 13:46 +0200, Rémi Denis-Courmont wrote:
> Hello,
> 
> On Mon, 17 Oct 2011 23:06:24 +0200, Patryk Zawadzki <patrys at pld-linux.org>
> wrote:
> >> a) Let's have a video player that uses HTTP to download a movie and
> >> its subsequent play. This player should not register
> >> x-scheme-handler/http, right?
> >> b) Another video player that uses HTTP as a transport protocol for
> >> video streaming. This player may register x-scheme-handler/http?
> > 
> > Claiming to handle "x-scheme-handler/http" is basically saying "I can
> > handle anything that you throw my way as long as it's HTTP".
> 
> There is no applications that can handle ANYTHING over a byte stream
> protocol (file, http, ftp...). It's purely historical
> first-come-first-serve that the web browsers are the typical handler for
> HTTP.
> 
> After all, a file manager or a download manager could deal with "anything"
> just as well as a browser - if it passes HTML pages to the browser,
> documents to the office suite, video to the media player, etc. Certainly,
> it would ruin the browsing seamless experience... just like not giving the
> media player HTTP video URLs ruins the streaming experience.

I'm not sure whether you're trying to be playful, hard to work with, or
just bashing the possibly bad wording that's in the spec. I'd rather
something constructive. If the goals of the x-scheme-handler/ mime-types
isn't clear, then I'd rather have proposals for better wording.

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

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