Just open-sourced an NPAPI plugin for File IO that I created with Firebreath

[ryan]

I just wanted to say thanks to the Firebreath team for an awesome
framework and show off my final product. I didn't run into any major
bugs or problems using Firebreath to create a cross-platform NPAPI
plugin. Firebreath is an awesome framework.

I used Firebreath to write an NPAPI plugin for doing various native
File operations. For example, it can read and write files, it will
open a folder dialog, and it can watch folders for changes to the file
system. It supports OS X, Windows, and Linux. I used boost::filesystem
for the basic stuff but I wrote platform specific code for other
things. The source is hosted on Bitbucket

https://bitbucket.org/ryanackley/npapi-chrome-file-api/src

I specifically targeted Chrome but it could theoretically run on any
Firebreath supported platform, I just haven't tried. I think there is
one place where I cheated and cast a few objects to their concrete
NPAPI types. You would have to change this if you wanted to compile it
as an IE ActiveX control.

I wrote the NPAPI plugin for a Chrome extension I wanted to create. If
you're interested you can find more information about the Chrome
extension here

http://tin.cr

[Jarom Loveridge]

looks like a cool project

[Richard Bateman]

On Jul 21, 2012, at 11:53, ryan wrote:

> https://bitbucket.org/ryanackley/npapi-chrome-file-api/src
>
> I specifically targeted Chrome but it could theoretically run on any
> Firebreath supported platform, I just haven't tried. I think there is
> one place where I cheated and cast a few objects to their concrete
> NPAPI types. You would have to change this if you wanted to compile it
> as an IE ActiveX control.

You did indeed cheat and access types that were not allowed in FireBreath proper... and unnecessarily. I wish you'd just ask me for some suggestions as I could have told you how to do what you wanted without resorting to NPN_Evaluate in that way. There are several options.

This is a great project, at least as an example. It would be terribly dangerous to make this plugin common on most systems as there is no security, but it's useful in a chrome extension; if you would like to make it a truly useful FireBreath example (which is of course up to you) I would offer the following suggestions:

1) Remove the string "NPAPI" from the prefix of all of your classes. In fact, remove it from the project name; as a possible replacement consider "firebreath" or "plugin". This is not written in NPAPI and it's likely to confuse anyone who doesn't know the difference.

2) Pass all your std::string parameters as const std::string&; this isn't really a big deal, but each time you do that without the const & it does an extra string copy, which just seems silly =]

3) NPAPIFileIOforChromeAPI.cpp line 250: don't ever do this. Creating a new NPObjectAPI yourself like that is both dangerous and completely unnecessary. It could cause, at best, memory leaks. It could cause, at worst, memory leaks.

It appears that the only reason you are using this method is so that you can use NPN_Evaluate, and since you've already shown elsewhere in the code that you understand how to use JSON.stringify, why not just use JSON.parse? In addition to not requiring you to bastardize NPAPI code into your otherwise beautiful FireBreath code (hey, I may be biased but that doesn't mean I'm wrong) it also has the definite advantage of being safer and will work on any browser you're likely to try to use something like this plugin on (particularly since other than an example it is too dangerous to use except as a private plugin in a chrome extension).

4) Potential crash: if launchFileSelect is called before AttachedEvent is fired then the PluginWindow will be NULL and your dialog code will crash. Call GetWindow() first and then check to make sure it isn't NULL before you call into the dialogmanager.


5) Add firebreath as a submodule:

git submodule add https://github.com/firebreath/FireBreath.git firebreath

Then add prepmac.sh and a prep2010.cmd files that call:

./firebreath/prepmac.sh . build/

This way you can check out the project, submodule update --init, and then just call ./prepmac.sh etc and it will just build and just work. Also it has the advantage of not changing the version of FireBreath that it will be built against without you doing it intentionally.

-----

Hope that was useful and at least food for thought.

Richard

[ryan]

Thanks Richard for taking the time to look at it in-depth and offer
advice. It's invaluable.

-Ryan