XWT: The Universal Client

adam_megacz writes "XWT is a GPLed 'universal client' -- an end run around the current state of client side OS lock-in. It lets you write applications that run on a server yet display their user interface on any client machine. Unlike VNC and X11, all UI operations are performed on the client, so it doesn't suffer from lag or freeze-ups when you lose your network connection. It also doesn't require a you to download/install/configure anything since the client is delivered as a Java Applet or ActiveX control (Linux native client also available). There are some cool demos on the site, including an email client and a widget sampler."

Comments

Re:Security warnings?

[SlickMickTrick]

Yes, signed applets are a Java 2 concept, much like signed ActiveX contorls. They can do anything they want to do on your computer, that's why it will complain loud and long if the applet is not signed by one of the big companies in your JRE's trusted list.

Re:Interesting

[baka_boy]

It *is* effectively just a "very light java applet...that just makes all calls across xmlrpc". However, the UI itself is built from JavaScript, a custom XML format, and PNG graphics, rather than Java code.

That's both a good and bad thing; it's good it you write your interfaces by hand, or want to generate them on the fly from some external data source, but it's bad if you like to use a RAD tool to prototype your UI by dragging and moving UI elements on the screen graphically.

Re:Universal *GUI* Browser

[Tablizer]

(* How about a universal web browser? *)

Not web, but *GUI*. Web browsers and HTML + DOM + JS are optimized for e-brochures (presentation), and not business forms. Intranets and B-to-B keep trying to make web browsers act like VB/Delphi/PB GUIs, and it is a royal pain in the ess.

BTW, I propose a competitor to XWT, called SCGUI (Server-Controlled GUI) at:

http://geocities.com/tablizer/scgui.htm

The demo is admittedly far less mature than XWT, but it is the concept which counts. It has a thinner-client philosophy than XWT. Downloading Turing-complete scripts and applets is too big of a security risk and increases versioning headaches IMO. Thus, no Turing is where it is at.

vs. Curl

[hstearns]

Neat stuff. I do want to straighten some things out wrt Curl:

"1.8 What other technologies are similar to XWT?
CURL Surge is a similar framework, although it requires per-use licensing fees and is a bit baroque."

Actually, Curl offers a variety of licensing arrangements, including per user, per site, etc.

I think XWT and Surge both aim to combine the benefits of native applications:

responsiveness, interactivity, and so forth
with those of server based software:

administration: install, update, secure data storage

"Browser as user environment"

security for user machine and for site

However, XWT focuses on what I might call a UI server approach. It can do more, but it is optimized for working only with an application's user interface while the application computations take place on the server. This specialization is consistent with the the separation of UI vs other design concerns, and has a lot of good characteristics, such as in the size of the initial platform download, potentially the size of the initial applet download, and the scope of learning required from developers.

Surge can be used in exactly the same way, but it is designed to handle more complicated application logic right on the client. You can make any separation you want (between client & server; between data, logic, and presentation; between different modules or levels of any of these), but you can also combine them within the same environment when appropriate. Technically, this provides a fuller range of application richness and deployment scalability, but there are other concerns such as learning, or how universally the platform is available.

In light of this difference in emphasis, I'm wondering which parts of Surge the author finds baroque. Let us know, Adam.

Another slashdotter also commented on the XWT FAQ's comments on source code vs. binary. I don't know how it works out in XWT, but Curl applets are in source so that they can be compiled to very fast native instructions on the platform they'll run on. Specific client resources can be utilized (e.g., for graphics), which a byte-code-JIT would have a hard time doing unless the byte-code included some pretty darn high-level instructions. Also, source code is much more compact than low-level machine or JVM instructions. Since compilation is much faster than the network, that gives a quicker total time from http-request to execution. If people are worried about protecting their applet code, they can obscure, encode, and compress it. Surge has a pre-parsed delivery option for code that does this.