Project still maintained?

[Evan Martin]

It might be worth trying to track down the original developer explicitly.
Otherwise, I fully endorse you merging the patches and fixing bugs.

On Sat, Mar 5, 2011 at 11:49 AM, David A Benjamin <davidben at mit.edu> wrote:
> Hi all,
>
> So, is this project still being actively maintained? I was working on a
> crash that resulted from a race condition in nspluginwrapper[1]. I've
> written a patch[2] for it, but I can't find an upstream to send it to
> anymore? The website listed doesn't exist anymore (and I came across this
> list on accident googling). As far as I can tell, distros are just
> maintaining piles of patches on top of the most recent release. (I ended up
> just filing bugs with a couple distros for my patch, but I'd rather not go
> hunt down all of them.)
>
> In working on the fix, I think I've become mildly familiar with the code,
> and have worked on a simple NPAPI plugin of my own[3]. So, if this project
> is actually abandoned, I'm thinking of perhaps adopting it. I was thinking
> of starting out by looking at every distro's patchset, try to reconcile
> them, and put out a new release with the ones that seem reasonable. And I
> guess things can go from there. I wouldn't expect development to be hugely
> active and, if nothing else, consolidating all the conflicting distro
> patches would be a huge improvement from the current state of affairs.
>
> So, if anyone's still on this list: Is this project really abandoned / would
> a new upstream be helpful? Also, does anyone have a copy of the original
> repository this was kept in. Otherwise, hunting for tarballs should give a
> little history; I've found 0.9.91.5, 1.2.2, and 1.3.0.
>
> Oh, I should probably disclaim: my interest in this project actually working
> is that I need it to to run a 32-bit Flash on 64-bit Chrome. When Adobe puts
> out a stable 64-bit Flash or Chromium implements the 64-bit/32-bit
> out-of-process translation itself[4], I won't use it anymore. But I guess
> the former condition applies to most using it, and the baton can be passed
> to someone else.
>
>
> David Benjamin
>
>
> [1] http://crbug.com/53940
>
> [2] https://github.com/davidben/nspluginwrapper/commits/master
>
> [3] https://github.com/davidben/embedded-emacs
>
> [4] All this logic should be in the browser anyway; Chromium and Firefox
> have some limited freedom to make NPP calls asynchronous/reorderable.
> nspluginwrapper cannot by design as it speaks NPAPI on both ends. In
> particular, my fix for the NPP_Destroy race actually discards NPSavedData in
> some cases because the NPP_Destroy must return earlier. Chromium apparently
> doesn't implement NPSavedData at all, but that's not the point. :-)
>
> _______________________________________________
> Nspluginwrapper-devel-list mailing list
> Nspluginwrapper-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/nspluginwrapper-devel-list
>