Hello, On Mon, 17 Oct 2011 23:06:24 +0200, Patryk Zawadzki <pat...@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/ _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg