This is a project that will require C++, Java, Qt, Boost, and other cross-platform Java/native skills.
As it's apparent now that the official Java Applet plugin will not evolve further and that the Java FX project focus on desktop rather than browser applets I think its time for a community effort.
In other news the lightspark project are working to create a free implementation of Adobe Flash. From my point of view they have the same problem that the Wine project have. They are trying to run application written for a badly documented proprietary product.
My plan are the following:
Create a plugin by forking icedtea web. This will reuse existing code while allowing us to change what we need to do different. First we will give our plugin a cool name that does not include Java or Applet (sorry but the FUD against Java needs to be avoided). Secondly we will not use the standard applet tag, because we will not be compatible. We will make sure that users can continue to run standard Java Applets with the existing plugins for their platform.
To make the platform secure and trustworthy we will stick to the original sandboxed applet model, we will not allow software to contain code that runs outside of the sandbox. With this we will avoid the main security problem with Java Applets.
As another security measure we will provide applets with a secure and reviewed API. We will not just allow them to access anything Oracle adds to the classpath, but each class and function will be reviewed from a security perspective. Many classpath classes could very well run inside the sandbox, and perhaps they will.
Accellerated 2D and 3D API: As we will not allow applets to ship with stuff like a signed OpenGL library but want to compete with flash we will have to ship our plugin with a class library gives applets access to 2D and 3D accelleration. The problem here are that direct access to API:s such as OpenGL are dangerous. For example OpenGL shaders can freeze the graphics pipeline (by not ending). Therefore I suggest scene graph library that by obvious reasons have to perform well while being secure. 2D could be implemented on top of a 3D API. However we have to make sure that we do not go down the Java 3D path which never made it to the classpath. Rather something lightweight and incomplete like WebGL, than something that we are unable to ship.
Last we need multimedia capacity which I suggest implementing by wrapping the Qt project. Qt have a lot of useful stuff that would be nice to wrap into our project. For example it have a media player API which Java lacks (JMF seam to be quite dead). By using Qt to play media our plugin can be used to for embeddable media players.
We will need both C++ developers that can work with the plugin and with native libraries like Qt and Boost. Ultimately we will have a modular design where a "QtPlugin" project makes it possible to write multi-browser plugins rather than just our plugin.
Hacking JNAerator to generate Java bindings our native code, or hacking our native code to play nice with JNAerator, will be other needes skills.
And of course making the actual classpath API:s that applets will be allowed to call will be a big part of our project. Without them there our plugin will be very uninteresting to users.
If you want to hack on something just to learn, great: hack away. But if you want to create something that people will actually use, there are probably much more productive uses of your time.
Just my humble opinion. YMMV. I would love to be wrong in this case.
(Personally, I disable all plugins on all web sites -- If it isn't in HTML5 or PDF, I will never see it: there are too many other things to do to waste time dealing with Flash etc.)
First of all what I suggest are replacing a single de facto standard for applets/rich clients, flash, with an open source alternative.
There are really only two options here. Accept Flash which are the only current competing standard applicable to the use cases we are discussing. The other option are to create a new open standard which are designed to be easy to implement and reuse as much existing FOSS technology as possible. Well of course one can always write an open standard that are hard to implement and do not reuse existing technology, like the Chromium team are doing with Native Client. The first option are being done by the Lightspark project in what I consider a very slow pace, which are not surprising as they are implementing support for a proprietary standard from a corporation that have no interest in clones. And the third option where we find Native Client, that thing are even more incomplete than Lightspark.
What do you suggest I spend my efforts on in order to get a FOSS alternative to the proprietary Flash player? Lightspark? Native Client? Because seriously think that I have to put a lot more effort into making any of those two to do what I want a FOSS plugin to do.
That xkcd may be true in some cases, but the more usual result are that there are less competing standards after an attempt to do what the stripe proposes.
For example creating a new standard to replace several previously competing standards worked out pretty well for C++, Java and many other open standards and FOSS projects. Even quite crappy standards like XML did a good job when it comes to decrease the amount of existing standards. In fact most packages I have installed in my distributions are based on new standards meant to replace old standards. I have Firefox meant to replace Internet Explorer (I was there in the trenches installing Firefox everywhere even if it could only view like 5% of the web).
Its a fact that rich client engines/applets are used by a lot of users. There are only two standards for those today, Flash and Java Applets. Its also a fact that among these two, Flash are the clearly dominant rich client engine because of its better graphics and multimedia capacities.
Neither HTML5 nor PDF covers the use cases that Flash and Java Applets cover. If they did, they would be used on YouTube and the various other sites that use Flash or Java Applets. Those two standards may be enough for you, but that makes you part of a quite small minority.
Yeah running a VNC client are actually a use case for me, and probably for many others. However I do know that I am in no majority with that. The real reason people use flash are video sites like youtube, and browser (zero install) games.
"Those two standards may be enough for you, but that makes you part of a quite small minority."
Exactly. That's why I said YMMV.
As a communicator -- someone with a message to share with another human being -- the choices are simple: If I need more than text, audio, and video then I'd better count on my audience being offline, haul out the real canvas, and paint or sculpt, etc.
Beyond these communication use cases, a browser is an awful place for an app to live, so go ahead and use Swing or Android or whatever.
Rather than spending time creating a new platform, you might use an existing platform to create something that meets a need. I know it's more fun to build a platform/tool than an app, but someone has to do the boring stuff. ;-)
Why are brower games not a valid use case? We are not talking about you and never was, we where talking about those that currently use Flash and have a use case for it. That's the majority of Internet users.
I am proposing to use an existing platform and modify it to create something that people need, more precisely building upon the extensive work Sun and Oracle put into Java and Java Applat.
If you have another suggestion that will take less effort while providing native performance, go ahead and present it.
I can help you with this project. I've been working with C++/Qt, boost, have some Java skills.
Then you have a lot of experience gain from this project(s). The first thing we need are someone that understands Icedtea-web and browser plugins so you may want to start with downloading Icedtea-web and browse its sourcecode. Remember that we may want to create a QtBrowserPlugin as a layer between various browser plugin models and our plugin. That will enable us to share effort with outer browser plugin.
If we do a good and easy to use library for browser plugins we may share code with other projects like lightpark. However you cant view that code as its GPL3, but if you find plugins that's license-compatible with Icedtea-web you can use that code.
Chromium is going to drop the NPAPI support. It seems that Icedtea-web uses NPAPI. How will you approach this problem?
First of all this are an upstream issue that's not isolated to our fork.
That's one reason to make a "QtPlugin" lib, and not code directly for NPAPI. The Chromium white-listing of plugin:s can be solved by writhing a patch to Chromium, I have already asked the Chromium developers about this. And if we get the Chromium developers to like us, we we may get them to add our plugin to the official source tree.
Current Chromium packages in Linux distributions depend heavily on NPAPI so I do not think that this are something we have to worry about for quite some time, very few people use the actual upstream Chromium sourcecode without any patches.
Chrome however may become a whole different problem, but not really a FOSS problem.
Currently Flash only works in Chrome if I want the latest version of Flash on Linux, so for me having a plugin that works in everything but Chrome ain't that much of a problem.
Also when I speak with Chromium/Chrome developers they give me the impression that the Flash binary blob are something that they would rather get rid of, if they had an alternative.
My answer here are that if we make something good enough to replace Flash, we o not have to worry about Chromium/Chrome. They will import our plugin to their source tree.
Oh, and on second thought it should be QtBrowserPlugin, not QtPlugin.