shared mime info: URI scheme handlers for non browsers

Rémi Denis-Courmont remi at
Tue Oct 18 04:46:52 PDT 2011


On Mon, 17 Oct 2011 23:06:24 +0200, Patryk Zawadzki <patrys at>
>> 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

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

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

Rémi Denis-Courmont

More information about the xdg mailing list