MozillaZine

Mozilla Foundation, Apple, Macromedia, Opera and Sun to Improve Browser Plugins

Wednesday June 30th, 2004

The Mozilla Foundation is teaming up with Apple, Macromedia, Opera and Sun Microsystems to improve browser plugin technologies. The alliance will work on the extending the Netscape Plugin Application Program Interface to enhance interactivity and scriptability. Mozilla, Opera and Apple's Safari browser all use the Netscape plugin model, which debuted in Navigator 2.0. Meanwhile, Macromedia develops the popular Flash Player and Shockwave Player plugins, while Sun is behind the Java plugin. As well as Safari, Apple is also responsible for the QuickTime Player plugin. The only notable browser/plugin developer not in the new group is Microsoft, which dropped support for the Netscape plugin model in favour of ActiveX at Internet Explorer version 5.5. Slashdot has a story about the new plugin alliance.

Update: Adobe has been added to the members of the alliance listed in the Mozilla Foundation's press release.


#24 Absolutely a good idea - what I'd like to see

by leafdigital

Thursday July 1st, 2004 2:20 AM

You are replying to this message

No, it *is* a good idea - that's exactly how plugins should work.

In addition to the current model (plugins support particular file MIME types) and enhancements to that model (allowing plugins to integrate with the page rendering engine so that you can have plugins underneath other things, transparent plugins, etc) which is presumably what is planned, a new plugin system should also allow for XHTML plugins that handle areas of the DOM tree specified by certain namespaces.

So you could have a MathML plugin, an SVG plugin, a MusicML plugin, ... that could all work with inline content rather than content from separate files. They could also handle standard DOM scripting, so in Javascript if you wanted to change something within your MathML equation or your SVG graphic (or create a new one on the fly) it would 'just work', as it works right now at least in theory with formats that are supported natively by the browser (i.e. MathML).

In Mozilla right now this would give the advantage of removing SVG code from the monolithic Mozilla project and making it entirely separate, meaning that those who want (unfinished) SVG support could simply install a plugin rather than having to use a completely different binary. Of course in the long term something as core as SVG might be used internally for icons and such, so it might be better to keep it inside, but...

You could make a TeX plugin like that if you wanted to, just have to namespace it like <tex:equation> or something, presuming you'd previously defined the tex namespace prefix. However, it would probably make more sense to use MathML, even though it's more longwinded.

I don't know if the new alliance is considering this type of issue, as there seems to be no technical detail available (perhaps discussions are only just beginning). I hope they are though as it would be a real win for XML; a standard, cross-browser way to implement browser support for your own formats, which would be very useful within niche interest, enterprise intranets, and so on.

Another thing I'd like to see is standard support for plugins in other formats apart from native binaries. Particularly Java support would be nice - since browsers generally already integrate with Java, it should be possible (not necessarily easy but possible) to allow plugins to be written as Java .jar files. Then you'd get cross-platform, cross-browser plugins that are easy to develop. (It would of course also be worth considering whether JavaScript plugins are a possibility too, as browsers provide JavaScript engines.)

Finally on the issue of XPI, which is of course orthogonal - XPI plugin installers for the common plugins would certainly be welcome if they could be designed to simply make the plugin work without any install user interface and not install crap all over your system that launches on startup/displays icons in your tray/etc. I can't see companies like Real going for that option though :)

--sam