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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
