AppletServerBut wait, what about the code we already have?
"Any Toolkit, Any Deployment"
WebCreamCreamtec created WebCream back around the same time I created the first AppletServer implementation. It also is based on server-side Swing but they've stuck with it all these years and have a pretty solid-looking product.
New EntrantsThis is an idea whose time has (finally after 8 years) arrived. New projects have sprung up in the wake the AJAX wave.
This framework constructs and handles html pages with Swing components, allowing to use MVC architecture and all the facilities provided by Swing in the web.
AWT & Swing
Netbeans, GATE, SWOOP, Protege, ArgoUML
Illustrate Eclipse deployment options (reference to Eclipse/SWT on Java Web Start) including SWT-on-AWT (for a no platform-specific binary install) and as a web application using that on the AppletServer.
- Eclipse on Swing
In keeping with the principle that when creating new applications one should strive to make them at least as good (if not better) than those that have come before, online or webapp "office" tools should work at least as well as Microsoft Office. This is contrary to current practice and expectations (which go hand-in-hand), as exemplified in this recent review article:
While OpenOffice might seem the logical place to look for a full-featured office suite that strives to be at least as good as MS Office, there is actually a better starting point, NeoOffice.
NeoOffice is a port of OpenOffice to Mac OS X that has a native (Cocoa) GUI. What makes it especially interesting as a starting point for a web office suite is that they used the Java bindings.
Java is much better suited to implementing reliable GUI applications than C++ (the language OpenOffice is implemented in), or even Obective-C (the language Cocoa is implemented in).
Also there is WebObjects, the NeXTSTEP GUI in Java for implementing web applications. While it is not OSS, at least Apple is giving it for free now (at least on Mac OS X).
The AppletServer technique is now being pursued for X11 in the XML11 effort. While that could be applied to OpenOffice, I don't believe such a low-level API will be as effective as Cocoa/OpenSTEP. But that is not a categorical judgement because either approach will need to use adaptive templates to optimize the user experience.
#1} Even if it isn't the best that has come before, it is certainly the benchmark for such applications today.