|
Chronicle of the Xul Revolution |
Droplets Inc., a New York startup (http://www.droplets.com), going nowhere with yet another single-vendor, closed-source remote GUI toolkit dubbed Droplets, ignores Web Start and XUL.
Sun headlines a Droplet article entitled "Droplets Brings GUIs to the Internet: Droplets enable developers to combine the Web's ubiquity with a desktop GUI". Check out samplings where Droplet head honchos boasting Harvard degrees blissfully ignore Web Start:
"Droplets are apps, written in Java, that look and feel exactly like locally installed desktop apps," explains Lou Franco, chief software architect for Droplets. "They have all the speed and responsiveness and interactivity of apps that are locally installed, but they are deployed like the Web."
The need for easy-to-create Internet apps with the interactivity of desktop apps is now being met by Droplets.
Droplets enable developers to create apps that combines the convenient, instant deployment benefits of the Web's thin client architecture with the high usability and rich UI of fat clients.
Read the full article at http://java.sun.com/features/2002/08/droplets.html
An older article published in the XML Journal entitled "The Next-Gen User Interface: How remote GUIs are making old-style Web UI programming obsolete" written by Russ Atkind and Sean Harvey (Droplets Inc.) proclaims Droplets as the UI of the future outshining XUL and other contenders:
XUL is not quite like anything else UI developers have worked with before, but its component technologies will seem familiar. Like HTML, the widgets in a window are described using XML. Cascading Style Sheets (CSS) provide the appearance parameters, and JavaScript is used to handle events and invoke business components. But the end result is quite different: XUL renders component-based GUI applications that behave like traditional desktop software.
Now the attack begins:
Is XUL the UI of the future? If it could be served remotely via a thin client (like HTML), it could solve a number of "Web services" UI delivery problems. Unfortunately, its bandwidth requirements are extremely high and it can't provide the asynchronous UI updates to support interactive applications like stock watchers or IM.
Wake up boys. You can play with the XUL UI on the client as easily as with any other UI toolkit (such as Swing, Gtk# or whatever) and without any server-roundtrips.
There are several obstacles. First, to be a truly ubiquitous remote UI platform, a UI needs to adapt for display on different devices. While XUL shows promise in this area because of the inherent transformability of XML, it currently requires an extremely heavyweight client-side engine. In addition to an HTML renderer, the engine must embed a JavaScript interpreter and an XML parser, and support for CSS, the XUL language, and the XPCOM component model - essentially the entire Mozilla browser.
XUL no longer is a Mozilla only-affair. Web Start lets you pull down the Luxor XUL toolkit with a single-click. And more important Luxor unleashes the power of Java and Phyton and frees you from JavaScript.
Second, there needs to be a way to communicate between the front and the back end. Unlike HTML forms, XUL doesn't automatically send the data entered by the user back to a server whenever the user clicks on a widget. This is in fact an advantage, since there's potentially much finer-grained control over how and when that data is sent. But the plumbing has yet to be built.
Using Java you have whatever plumbing you wish for (XML-SOAP, XML-RPC, RMI, HTTP, JMS, JDBC, CORBA, IIOP, TCP, and so on) and you can even pull-down not-yet-invented plumbing automatically using Web Start.
Read the full article at http://www.sys-con.com/xml/articleprint.cfm?id=297
Please send comments on our web pages to our public xul-talk mailinglist or to a member of our web team. | Copyright © 2003, 2004, 2005 Open XUL Alliance |