shared mime info: URI scheme handlers for non browsers

[Rémi Denis-Courmont]

   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.

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

As far as I am concerned as a maintainer of VLC media player, this
proposal is broken by design. We are going to stick with the KDE
X-KDE-Protocols approach, since It Actually Makes Sense(tm) and it seems to
work.

-- 
Rémi Denis-Courmont
http://www.remlab.net/