[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Nspluginwrapper Update Status

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 ;-)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]