I'm probably being dense, but what does this actually do? I get that it's cross-platform and that it's a plugin architecture, but what does the plugin architecture actually enable?
As far as I can tell, it lets you create new browser functionality in C++ and expose it (to arbitrary websites?) via Javascript APIs - am I close?
Plugins allow you to run custom client-side code (that has access to the OS and its services) inside the browser. The most popular browser plugin is Flash. It is implemented both as an NPAPI plugin (which is supported by Firefox/Chrome/Safari) and an ActiveX component which is supported on IE.
Other plugins include the QuickTime viewer for watching quicktime video.
The cross-platform framework allows you to keep one codebase for both types of plugins, which, I presume would encourage developers to write plugins since it's now easier to make it work on all major browsers without having to learn two sets of APIs.
You can normally see plugins that are installed in your browser by visiting about:plugins
But yes, I'd love to see more samples, especially not just cross-browser, but cross-platform. Can anybody tell - would a FF plugin made with this work on both OSX & Windows? I can't imagine it would... So this project would let you keep a single codebase for each of win/linux/osx, which is better than having separate codebases for each browser on each platform. Maybe?
I'd say about 90% of the code can be cross platform; some things you'll have to implement seperately, such as the drawing library, since that doesn't work the same on each platform. FireBreath abstracts most of the differences, though. For example, it isn't a shim to let npapi plugins work on activex; it's a shim for both npapi and activex plugins, which means it's easier to write something in firebreath than it is to write it using npapi as well.
If you aren't doing any drawing, just network stuff and calculations, you can probably get by without writing any platform specific code.
So this is different from the recent Google, Mozilla, Adobe announcement that they were going to introduce a new, faster, safer browser plugin standard?
It's just a compatability shim so your code will work in IE as well as the NPAPI-supporting browsers?
Also a great project; nixysa and FireBreath have a core difference in approach, though; nixysa is basically a code generation tool to simplify creating npapi plugins.
FireBreath is a framework that abstracts npapi and activex (but could be extended to abstract other types of browsers as well, if there were reason and someone wanted to) to make it easy to write your own code that works in both places.
Why would I use this instead of Native Client? edit: I really don't understand this either. How does this fit in with the Chrome style of extension? What is NPAPI? How does it relate to Native Client? ActiveX? Firefox Extensions?
Clearly I know very little about the current browser plugin ecosystem. Anyone care to enlighten me?
NPAPI's lineage harkens back to Netscape 2.0 where it was used for extending the browser to support new content-types. Other browsers of that era implemented the API as well so it became a bit of pseudo-standard. It's been updated over the years in various ways, some bad, some good — allowing bidirectional interaction with JS and not requiring the plugin to render something to the page are probably the main improvements to note.
NPAPI is useful in the context of Chrome extensions as it is the only method (currently) available for running native code in an extension. Firefox extensions are able to bundle NPAPI plugins in this manner as well however this is a less common approach as XPCOM components are generally a better fit for that environment.
One notable difference between extensions in Firefox and in Chrome is that Chrome allows you to specify that a plugin is only executable by your extension; a handy thing as you may not want any arbitrary web page to run your plugin (XPCOM components are not by default accessible via any old webpage).
Internet Explorer no longer supports NPAPI which is why ActiveX support is a useful target.
Native Client as far as I understand is targeted more towards producing one-off executables rather than reusable components.
actual plugins aren't useful for all situations; in fact, I'd say that it's relatively uncommon to need to write a plugin.
That is one of the main reasons I started FireBreath; relatively few people in the world know how to write a browser plugin for any platform, much less make one work on all major browsers. FireBreath aims to make that easier. That shouldn't preclude the fact that plugins simply aren't suited to many tasks; the need to install it is a big factor in that, particularly since most common install methods only work on one browser. Also, there are existing plugins such as flash and silverlight that already have a large install base and can often be used to solve many of the problems that people use plugins to solve; worth considering.
As far as I can tell, it lets you create new browser functionality in C++ and expose it (to arbitrary websites?) via Javascript APIs - am I close?