[maemo-developers] passing arguments to hildon applications

[From: josh.soref at nokia.com]

On Tue, 27 May 2008, josh.soref at nokia.com 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 <advax at triumf.ca> 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.