On Tue, 27 May 2008, [EMAIL PROTECTED] wrote: > Fwiw, at the present time, video/x-ms-wxv is among the "hacks". These > "hacks" were requirements. We're hoping that some future version may > lose some or all of these hacks. But don't hold your breath, I've > been holding my breath for two years and only just now got a sign > that maybe something might happen eventually.
Andrew Daviel <[EMAIL PROTECTED]> wrote: > As I recall, these "playlist" content-types such as WXV, WXA and > Realmedia RAM are required because the browsers do not > understand RTSP URLs. I don't want to try to dig through my memory for why they were created. Our browser has *different* hacks for rtsp and similar urls. Actually, I can say for certain that feed: was created exactly for the opposite reason. Web servers wanted to ensure that some other application safely got a url. > So there's a short text file containing the URL of the > stream. Sadly from reading bugs, it seems that one microsoft mime type can mean either a stream or a playlist. I can't remember if this was by design or simply because the microsoft plug-in was tolerant and web sites were lazy. > For a video file available via HTTP, > using the playlist will let Mplayer stream it via HTTP, > otherwise you have to wait for the entire file to download. Our hacks are basically designed to address this unfortunate standard behavior for the non playlist case if you're using the normal plugin path. It of course doesn't work correctly for mplayer (although in theory it could work as well as it does for the standard player). and it doesn't always work properly in general... > It may be a hack, but I'm not sure how you'd get around it. Well, atm the browser has logic that should be in a plugin. How the plugin should be written should not be the browser team's problem :). I explained that when I first arrived, and maybe someday that might be the way it is. For people curious about NPAPI, the browser will give you a url and a chance to receive the data. You can choose to let the browser stream it to a file, feed it to you piecemeal, or not download it. > At one time I thought there was a mailcap variant that caused Netscape to > pass a URL to the helper application rather than downloading the file and > passing the filename. There is (%u), support for this has been poor for years. I can't remember how well n4 supported it, but generally speaking Mozilla support didn't exist until fairly late (iirc bz tried to add some support for it). http://www.spinnaker.de/mutt/mailcap has an example The problem is that by the time you have a mime type, the browser also already has a stream of the file, and if it's a one time stream or a stream guarded by authentication, passing the url to someone else means paying twice ($+$) and possibly not getting anything at all ($ -> /dev/null; 0 -> /dev/audio). > Or I guess you write a browser plugin. We have a strange browser plugin. Given the choice of this or a normal browser plugin, I'm hoping to get a normal one. > I prefer an external helper that doesn't take the browser with it when it > crashes... There are a number of strategies, but in the end, you'll lose. <audio> and <video> are coming to beta browsers near you by the year's end. * This is *not* a commitment by the microb team to include such a feature, merely a statement that prereleases of Safari, Firefox, and Opera will all include this feature in the near future. I can't predict when MicroB might get such a feature (we obviously need it for compatibility reasons). Audio processing can be done out of process, a plugin only really needs to accept a stream and set it to a different process for handling. It shouldn't even need to do much in the way of parsing. It *should* be possible for a couple of teams to write safe plugins which perform this sort of out of process implementation. There are a number of projects to do things like this, if only to enable 64bit browsers to host 32bit plugins, or for Qt based browsers to host Gtk based plugins. Actually, as far as browser crashes, diablo includes a feature such that the ui doesn't die when the engine crashes. It's not full sessionstore ala firefox, but we hope you'll like it. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
