Nspluginwrapper Update Status

[Martin Stransky]

On 04/01/2011 01:42 AM, David A Benjamin wrote:
> First is a fairly boring batch from Fedora that decreases the RPC
> timeout from 30 seconds to 10. The git commit says "Changed RPM [sic]
> timeout to 10 second, should prevent long browser hangs." Martin, you're
> on this list right? What was the original reason for this change? Both
> numbers are absurdly long for UI. Was this in case the plugin process
> exited or hung? If exited, the wrapper instead detect a crashed viewer
> better. If hung, it's not really hanging any more than would normally.
> I'd like to not focus on trying to improve the plugin and only recommend
> nspluginwrapper when your plugin is the wrong architecture. Both
> Chromium and Firefox already push plugins out of process, presumably
> already with hang/timeout logic, so this is just an extra source of bugs
> (and generally makes good on promises there).

I think it was because plugins hangs sometimes (in NPP_SetWindow for 
instance) and whole browser is frozen and waits when plugin finishes 
(NPAPI calls are synced). Some hang detector would be great here.

> Looking at Fedora's situation however, what if instead npw-config.c gets
> hacked to pieces and we add some npconfig binary with commands like
> npconfig is_plugin PLUGIN, npconfig is_wrapper WRAPPER, npconfig
> install_wrapper PLUGIN WRAPPER, etc. Then Fedora's plugin-config tool
> can be written in shell (or Python or whatever), and likewise Debian and
> Ubuntu can write their own things. Upstream can probably provide one
> compatible with the original for distros that didn't change it and maybe
> improve it later. I'd love to stop this madness where every distro does
> paths differently, but I don't think nspluginwrapper can fix this. And
> in the meantime, people have not yet agreed on a coherant way to
> discover and install multiarch plugins.

I wrote the plugin-config tool because we wanted to install the plugins 
when firefox was starting and it was meant to be as fast as possible. 
I'd use a combination of npw-config and python/bash script today. The 
speed is no longer an issue and plugin-config duplicates many parts of 
npw-config. Plus plugin-config is too complicated - it tries to detect 
changes and do only necessary replacements. So the new tool may just 
remove all linked/wrapped plugins and wrap/link them again.

> So, what are folks' thoughts about that? And if this is reasonable,
> should it be done now, or would it be better to save this for 1.6.0? It
> probably wouldn't be an insane amount of work, but it does also mean
> more friction for packagers to build the new ones. And possibly more
> sources for incompatibilities.
>
> I think this issue is the last on my list, other than further
> buildsystem cleanup (--with-lib32 is completely unused, and
> --with-lib64's remaining usage could maybe be replaced with LIBDIR or
> something). I was also going to see what other nspluginwrapper bugs in
> Chromium's tracker I can fix. And then I guess I can maybe make some
> final attempt to contact the original author and eventually get a 1.4.0
> out for all to enjoy.

Thanks for your work on this project! I don't mind to take any changes 
and merge them with recent Fedora packages. And I'd love to get rid of 
plugin-config ;-)

ma.