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?
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.
[+] [-] samstokes|16 years ago|reply
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?
[+] [-] statictype|16 years ago|reply
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
[+] [-] gte910h|16 years ago|reply
http://code.google.com/p/firebreath/wiki/FireBreathUsers seems empty still.
[+] [-] egb|16 years ago|reply
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?
[+] [-] vark|16 years ago|reply
[+] [-] ZeroGravitas|16 years ago|reply
It's just a compatability shim so your code will work in IE as well as the NPAPI-supporting browsers?
[+] [-] taxilian|16 years ago|reply
- Taxilian (original author of FireBreath)
[+] [-] est|16 years ago|reply
http://code.google.com/p/nixysa/
[+] [-] taxilian|16 years ago|reply
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.
[+] [-] drivebyacct|16 years ago|reply
Clearly I know very little about the current browser plugin ecosystem. Anyone care to enlighten me?
[+] [-] andrewtj|16 years ago|reply
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.
[+] [-] est|16 years ago|reply