Slashdot Mirror
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."
Their maximize button under the "Windowing" tab in the widget demo doesn't work right under IceWM, or any X wm for that matter because X doesn't have a notion of maximize.
Furthermore I found two places on the fonts tab where widgets overrun: the "font name" over runs the frame and the textbox, and "Sample" over runs bold.
-- Ken Kinder ken@_nospam_kenkinder.com http://kenkinder.com/
When launching the demo, I'm presenting with a "Java Security Warning". The applet is signed with a valid SSL certificate, but I've never seen a Java applet on the web pop up a dialog like this before.
Does this mean the applet isn't running in its own sandbox, since I have to confirm starting it? A friend of mine recieved a security zone rejection for the ActiveX when trying to load the demo in MS IE.
Sounds scary. Course, the major web browsers fashion the simple SSL warning dialog to scare the bejezus out of any vistor to a page that isn't signed by verisign, so this is probably nothing as well. Can someone with knowledge on this part of Java confirm?
Hmm Well there are first off all some serious screen redraw issues. Oh well. I am just uncertain what the advantage over Swing really is. The author mentions that it is easier to create XWT interfaces in XWT then in Swing but well with Borlands JBuilder is it really that hard?
I mean this does not seem like a bad idea. I hope it or something catches on because anything is better then long endless forms that are mangled to do things they were never intended to do.
The mail client is wonderful though. That alone makes it worth a bookmark.
I'd do something interesting, but my server can't handle a slashdotting.
(* Why? Java applets are Turing complete, but there's not much of a security risk in running one, because it runs in a sandbox. *)
I *have* read about applet holes. Even sandboxes can have leaks. Anybody have some specifics on this?
But, a bigger problem with Java is the versioning issues. It is so complex that you have to be careful about what version you are targeting.
Plus, complex applets take FOREVER to download. I once used an HR applet that took 25 minutes to download (via modem). Sick. You don't have that problem with browsers.
And, it exposes biz logic since applets are relatively easy to disect.
Without a local script/applet engine, I would say that a GUI browser is roughly about 1/3 as fragile versioning-wise.
The thing is, you *don't need* local scripts/applets to get decent GUI power. I agree that local execution will speed up some things, but not enough to justify the complexity and problems that go with it. It is like hiring a Gorilla to sweep the floors. It might do some jobs faster, but requires more babysitting and risk.
Table-ized A.I.
a little subtle, but crucial.
:) It's where HTML might be 5 years from now. Still can't resize a column without elaborate piles of browser specific JavaScript. The browsers are all broken one way or another. Frames are a pain in the ass to work around. Etc, etc. The Mozilla and W3 folks have this as a vision. Problem is it'll take them to another half decade to get there.
DHTML/Forms do not provide enough UI "fidelity" without radical workarounds. Java Applets/Swing are too heavy, have immature and non-native UI controls (I think "lightweight" controls were a mistake, because they look weird, which seems to matter a lot, and frankly Swing doesn't approach native fidelity) and require non-standard (yes, they are "standardized", but not ubiquitous) protocols. "Convergence" technologies (Citrix, VNC, etc.) do not scale to large enough numbers, and are doomed to whatever platform they expose to the client. XWT fills the gap in between neatly.
Business applications need something as stateless and lightweight as HTML (I know, "sessions" are state, but it scales easily and that's the point,) but with the same fidelity as native, local clients. XWT may be a good approximation of this.
Previous posts mentioned the following deficiencies of XWT:
o Various control problems; overrunning widgets with text, maximize button doesn't, redraw issues, etc.
If you go to the site and read the FAQ, you'll know that the release was not intended to provide perfect widgets. It's known they still need work. The release provides a working server and client "engine". Release early, release often.
o How is this any different than Java applets?
The client sides deals ONLY with controls/widgets. No JDBC or other elaborate protocols. It's technically possible to do this with applets, but that's not the model applets provide. Most applets try to behave like client/server apps. No language/platform support is provided "out of the box" to achieve truly thin (HTML-like) clients. You have to roll your own.
o Isn't this the World Wide Web (meaning HTML/Forms/CSS/DOM etc.)
Sorta.
o The renderer is monolithic
So are browsers. XWT at least give you the means to implement custom widgets. Java Swing or Applets are no better.
o Interactive Apps should be local
Tell that to the WWW.
o It doesn't replace VNC
Nope. Doesn't have to. VNC is a completely different problem domain. This is about cross-platform server apps, scalability and ASP distribution. VNC/Citrix/whatever do this poorly because; the application running on the server is platform specific, it requires more resources than a (near) stateless client and is unresponsive with poor bandwidth. However, if you need to crank a knob on a server in the middle of the night, VNC gets you there, as it should.
The one major problem I see:
There doesn't seem to be a "sandbox" notion. I read the material closely. Perhaps it's presumed. I didn't see any explicit warning about client side exposer, but I also saw nothing explicitly stating that the Turning complete UI is isolated. However, this may a feature that, if it doesn't already exist, can be added. Further, I know there are MANY applications where this is irrelevant.
I've had in mind a browser based "universal" UI platform that would allow a large class of business applications to go pure "thin" client. CRM/ERP/Collaboration software mainly. These apps require only slightly more UI fidelity than you can achieve using the most advanced DHTML/DOM techniques. Yet every vendor has their own in-house UI solution. Bah. XWT, with a bit more maturity, but no further fundamental changes, could implement these UI's neatly.
J.D. Edwards has a DHTML client to replace their "Fat" client. Their UI was already quite generic and the port is obvious. Siebel is about to release a DHTML UI for the CRM. Oracle went whole-hog early with a java port of their existing Forms platform. It's a bit of a mess.
Problem is I wouldn't trust any of the DHTML apps further than I could throw the building the programmers work in. I know there will be delicate dependencies on browser versions, coupled with lag between state-of-the-art browsers and the app vendors releases. Who want's more of that crap? Say you have two apps; one needs IE 5.5084321 and the other wants IE 6.0000123. You're screwed.
Custom, in-house apps could benefit also. Sometimes you need more UI than you can do in a browser without being a master javascript geek. So, you turn to some platform specific "development tool" mess. The runtime has to be distributed to the clients, better keep up with the tool vendor, etc, etc. XWT may have real potential because it gives you enough UI, without deviating from a near-stateless HTML-like model.