Slashdot Mirror
New Alliance Hopes To Standardize Web Plug-Ins
mksolutions writes "As reported on heise online and mozilla.org 'Apple, Macromedia, Opera and Sun Microsystems join in push to modernize plugins and create a richer web experience.' They are to develop a common, cross-platform plug-in interface which will be used in Mozilla products as well as Opera and Safari and will be released under an open source license."
Unless your kids are using Linux, the Shockwave plugin can be found here (Access this link with a Mozilla-compatible browser).
Anyway, there's no indication that this "consortium" would set a standard for plugins in that they would be cross-platform. That would be the ideal situation, otherwise it would not bring many benefits to this effort.
Just in case you were confused, this is about things like the Macromedia Flash plugin that lets you view Flash docs, not the "Flash Click to Play" extension of Firefox. Granted, having one without the other seems insane, but this article is only about the one.
The enemies of Democracy are
There is a Mozilla plug-in called Plugger which itself allows stand-alone programs to be used as plug-ins. This provides the desired feature of in-line viewing of formats not natively understood by Mozilla. But it also does another thing that other plug-in APIs misses, it seprates the stablity of the browser from the stablity of the Plugger'd viewer.
The Netscape plug-in, IE ActiveX and IE BHO APIs all allow the plug-in to crash the browser! Even worse, these APIs make it trival for Spyware to collect information including online banking username/passwords.
For the majority of plug-ins, all the plug-in functionality needed was a display system to provide their "window" in-line with the document. So, why then does plug-in APIs allow the program to run in-process with the browser?
I'm not playing the open source fanatic here, but I'd really like them (*cough* macromedia *cough*) to realize that Linux is more than Red Hat.
.tar.gz flash-plugin flash-gflashplayer
http://macromedia.rediris.es/site_ri.html
Fedora Core 2 flash-plugin (apt, yum rpm)
Fedora Core 1 flash-plugin (apt, yum rpm)
Red Hat 9 flash-plugin (apt, yum rpm)
Red Hat 8.0 flash-plugin (apt, yum rpm)
Red Hat 7.x flash-plugin (apt, yum rpm)
RHEL 3.0 flash-plugin (apt, yum rpm)
Mandrake 10.0 flash-plugin (urpmi rpm)
Mandrake 9.2 flash-plugin (urpmi rpm)
Mandrake 9.1 flash-plugin (urpmi rpm)
Mandrake 9.0 flash-plugin (urpmi rpm)
Mandrake 8.2 flash-plugin (urpmi rpm)
SuSE 8.x flash-plugin (apt, yum rpm)
Conectiva 10 flash-plugin (apt, yum rpm)
Conectiva 9 flash-plugin (apt, yum rpm)
Conectiva 8.0 flash-plugin (apt, yum rpm)
Debian flashplugin-nonfree (contrib unstable)
Gentoo emerge netscape-flash
Generic
Got news for you - scumware authors have already tried to target Firefox and Mozilla. The developers' reaction? Implement a "whitelist" system that only allows extensions to come from a small, fixed set of official servers.
I don't know about regular Wine, but CodeWeavers used to sell a product that has Wine-based Linux browser plugins for popular Linux browsers. Now it's integrated into CrossOver Office, as you see at:
c e/
http://www.codeweavers.com/site/products/cxoffi
Has anyone actually done anything useful with TenDRA yet? It seems like such a great idea, and yet there's so little interest...
macromedia's page about it
Mostly, flash started out closer to an image format than a 'rich client' and shockwave was supposed to be the rich client, but then flash got way popular and gained features, taking a big chunk of shockwave's market. Also, Flash-->flash, Director-->shockwave. Sort of anyway.
Nerd rage is the funniest rage.
Quite possibly. A hell of a lot of Safari work has already gone back into Konqueror, and don't forget that Konqueror can already load Netscape-style plugins.
So you're suggesting we dump html and move to flash? Ignore the open standard and move to something proprietary? I really don't think that's a good idea. There is a W3C standard for a Flash-alike: SVG. So far there's no full Free implementation yet.
and no reasonable way to bookmark "pages" (state). That is the killer of Flash as far as I'm concerned.
HAND.
Microsoft has thus far not needed it. The NPAPI standard is aweful compared to their solution. Just use Spy++ that comes with Visual C++ 6.0 to prove this to yourself. Sniff the window structure. You will find that an entire page in IE renders in a single flat window. This includes plugins. This means that web designers can develop HTML/CSS/Ecma code which floats menus over plugins (such as Flash). The plugins in IE really become part of the program, not just some overlapping window which is limited in layering capability.
The members of this committee being spoken of have had difficulties addressing this issue. It's obvious that unless you flatten the entire window structure of the page, it is likely not possible to get the proper z-ordering required in plug-ins. The committee is not sure how to progress on this point, but it is in fact the key limiting factor of the plugin architecture today. The plugins themselves are in fact quite easy to implement at the moment. NDA blocks me from saying why I know this, but they are VERY EASY to implement.
Scriptibility is a great feature that needs to be incorporated. LiveConnect was a total flop. Worst standard ever. It made things impossible for the developer. Plugin developers were required to make use of an interface called JRI to communicate with the Java engine. This was not a huge problem, but when Java progressed, JRI didn't and when JNI was introduced, browser had to somehow fake the JRI interface through advanced thunking calls. Java makes a nice plugin, but LiveConnect is an utterly useless feature if scripting is supported.
Window handling is what may be considered the worst aspect of plugin implementation. Toolkits like Qt from TrollTech are fabulous since it takes care of the Windowing issue involved. Unfortunately, there's not proper cross platform solution for Plugin development which is freely available. If you want to develop a plugin for Windows, Linux X, Linux Qt Embedded, Mac OS 9, Mac OS X, Symbian OS, QNX, Palm, BeOS, etc.. the visual handling needs to be implemented completely different on each platform. Qt handles 4 of the listed platforms, but not the rest. There is just no solution for this problem. All the different browsers have their own methods of painting to the screen, so there's no logical method of exposing a standard API for this. A frame buffer isn't enough. So there is no method of making the graphics side of a plugin standard. If nothing else, it would be useful to clearly document and expose the NPWindow structure for each platform. Some platforms completely ignore this structure and simply use a window hack in the NPP_SetWindow() call.
I need to get back to work, so I'll summerize. Plugins aren't able to be made 100% cross platform. Microsoft has a system which works SUBSTANTIALLY better than the NPAPI interface and therefore the getting involved in the NPAPI development is a waste of time for them. After all, someone in the Moz project will just release a wrapper which will embed an NPAPI plugin in IE anyway. It's not the MS is against standards, it's just that there are A LOT of standards and since they have the market share they already have, the don't need to rush to fix their bugs or conform to new standards. After all, they still don't support PNG and that would be a few hours work for them.