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

Re: nspluginwrapper status

Hi Gwenole,

Thanks for the update.

I saw David volunteered to become the new upstream maintainer. I have
no objections, unless Martin wants to take the role since he has been
working on the project for a longer time. Thanks.

Martin, if you want to take the role instead, go for it (and feel free pull what you want from my repo); I won't be annoyed. Less work for me to do. :-D Otherwise, I'm happy to do it, and glad to have your blessing, Gwenole. It felt slightly weird before as to whether I should at least rename my fork or something...

I found an old backup (~2006) at home but this won't be enough. I
remember I once generated an svn dump for RH people too but since I
don't find anything in my archives, I believe it stayed in the (now
dead) server. However, what I still have are older source tarballs. I
also wondered if it wouldn't be possible to extract the data from the
Google cache, but I didn't have the time to investigate further.

I actually found most of the existing tarballs from archive.org and distribution archives. I think I'm just missing 1.1.6 and 1.1.8.


(Speaking of which, I probably ought to filter the repo and set the commit authors more accurately. Though there's enough history now that it may be messy. I really should have done that from the start.) Changes since 1.3.0 would be useful though, if you have them. The best I've found is an Ohloh listing, but it gives only diffstats. (But that may be enough to recreate things.) In fact, it seems you had already done one of my planned changes.


* The LSB stuff for ia32 can indeed die. It was initially desired so
that building on Debian systems is less effort. On other systems, this
is a non issue since they can easily build 32-/64-bit binaries or at
least install i386 packages on x86_64 systems.

(Aha! I thought it was Debian...) Yeah, I think Debian and Ubuntu are (FINALLY!) starting to transition to their grand new multiarch plan. I'll probably deal with that for 1.6.0 or later. I already have plenty of changes lined up for 1.4.0.

Speaking of which, hopefully this weekend or so I'll put out a 1.3.2 as a beta for 1.4.0. I do want a beta for people on development versions of distros or so to test; there are some invasive changes that should be stressed on more than just my machine. (If anyone has a chance to sanity check them, that would be great.)

One isn't even merged to master yet, but I will if it doesn't break my browser by the weekend (branch npobject-bridge). I rewrote the NPRuntime bridge to be like Chromium's; the existing one leaks proxy NPObject structures everywhere[1]. I also implemented a pass-ref mode for RPC so the delayed calls mechanism can be dropped.

The other reworks the RPC sync mechanism. There are a whole mess of crashes and bugs caused by interleaving. Instead of adding hacks for them one-by-one, I think it's better to obey NPAPI's assumptions[2] and sync around every event loop iteration. But it may visibly slow down browsers which do not do out-of-process plugins (i.e. everyone but Firefox 4 [3] and Chrome). I didn't notice anything, but I don't know what baseline snappiness to expect.

[1] It shared the reference count globally between the two processes, so if the plugin isn't last to release a browser-owned object (i.e. almost always), then it never gets informed of the object's destruction and the NPObjectInfo and bridge NPObject stay around forever.

[2] A browser with out-of-process plugins has the luxury of making some RPC calls asynchronous, and to use higher level requests when an operation requires two consecutive calls to be atomic. We don't.

[3] They added out-of-process plugins in 3.6.4, but only for some plugins. Intentionally or not, it appears the check rejects an nspluginwrapper-wrapped Flash.


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