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.
Wow, I thought I'd fixed that one. Could you please email me a screenshot and a description of what you were doing at the time? Thanks.
i must be daft, i dont see how this replaces VNC.
go ahead explain it to me like im a 12year old.
It doesn't replace VNC.
How about a universal web browser? One that's based only on standards. Of course, though, it'd be great if all browsers displayed web pages as they should be. Just an idea.
If you're religishitty, KILL YOURSELF!
This is a very interesting project, and I will be keeping a close eye on it.
.net does not seem to have mastered applet technology yet, this is probably the best choice for no hassle server based applications without all the annoying lack of HTML UI. I think I will spend the next few days looking around...and will perhaps even push this to the company since the design is quite simple -- even they will be able to understand how it works, and it will even use their precious .net web services (ughh) .....
Since I am stuck in a no java environment, and
However one question remains, though -- how is this really different from essentially a very light java applet (no slow AWT/Swing) that just makes all calls across xmlrpc. I am not too certain that one is easier to develop than the other.
And damn it -- how the hell did you make the ActiveX load, everytime I try to do that it gives me security issues -- I think the difference is your is signed. (And my company does not like paying money for signing controls)
Anyway -- this could be very useful, so, many thanks go to the author. Keep up the good work!
badness 10000
As for XWT vs Applets, please see this question in the faq.
A RAD tool for XWT is in the works; it'll look a lot like tekadence. The tool itself is written in XWT, so it's metacircular (oooh, big word...)
Either way, there are a lot of XP machines out there that will never get the service pack. But thanks for letting me know about this -- I'll revise the language in the FAQ.
Isn't that the world wide web? Doesn't the www already run applications in the backend ... and all UI on the client ?
--=.=-- www.cyber2000.qc.ca
I've never seen a web page that could do that.
The wonderful thing about the internet is that it shows us that if you think about something (without doing it yourself) for long enough, someone else will do it for you :-)
The differences between XWT and my thought experiments seem to be:
(1) The renderer is monolithic: I imagined a widget-by widget system in Java: sort of an outgrowth of how NeWS was supposed to work. Can XWT be extended in this way?
(2) The comms protocol is XML:euch. I'd imagined something compact and binary, perhaps Java's RMI. Oh, well, comms bandwidth is cheap as are parser cycles, they say.
(3) I'd imagined being able to wrap the host side inside something that pretended to be one of the popular widget sets, like GDK. Then my favourite X applications would have a chance to go where X hasn't. I haven't dug into the XWT doco enough to know _how_ the host side looks. Does it match one of the existing windowing models?
-- Andrew
What are the essential advantages of this technique over Remote AWT? AWT has the advantage of being the Java standard, and all most programs use it...
I've had this sig for three days.
This is reasonably clever, but I don't get the point. Ideally, interactive applications should be local. If the app needs remote resources, it goes and gets them -- but it still keeps the interaction part local. People only run interactive apps from a server when the local system can't support the application. (Unix users who access a Windows terminal server to run Word; graphic terminals that are deployed instead of PCs in pursuit of the "thin client" fantasy.) But this system makes you recode everything from scratch anyway -- so compatibility is out the window. It's server computing for its own sake!
(* 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.
Table-ized A.I.
Downloading Turing-complete scripts and applets is too big of a security risk and increases versioning headaches IMO.
Why? Java applets are Turing complete, but there's not much of a security risk in running one, because it runs in a sandbox.
Find free books.
(* 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.
(* [Examples...from memory...the tree elements: when selecting a sub element, the parent element is also highlit (highlightened? highligthted?) and the highlight does not easily go away...painful.] This has been fixed. *)
IBM's proposed competitor to swing (I forgot the name) decided to use navite OS wigdets if available (such as Window's tree browser DLL), or emulate them of not.
This may reduce such problems. Besides, 90% of all users use Windows anyhow. Java Swing's goofy behavior on Windows is a top complaint of Java. The IBM-backed version should be smoother, at least on Windows.
BTW, does Windows offer a native Grid DLL? All the Java grids I try suck eggs.
Table-ized A.I.
Regarding bug fixing:
Let's see who can write the simplest GUI browser using languages like Python, Tcl, Perl, etc.
If it is simple enough, then we can fix bugs on our own, or at least let OSS friends help.
To acheive such, one may have to keep the (server) protocol fairly close to the native API's used in those languages.
Table-ized A.I.
Yeah, this "World Wide Web" thing will never catch on....
What like Terminal Services??
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.
"4.1 Why are XWT applications delivered in source code form (like HTML) instead of a compiled form (like Macromedia Flash)?
.class files are nothing more than highly-compressed source code (if you don't believe me, try out "jad", the best Java disassembler I've ever seen)."
:)
Businesses are always nervous about distributing their code in source format. The creators of Java had to invent a binary format (.class files) just to assuage these fears -- despite the fact that
Hehe
The web is a client-server application, not a server-hosted application. Do I need to explain the difference?
XWT is a client-server application, where the client just happens to auto-download transparently.
Unfortunately RAWT still operates at a lower level than XWT -- it pushes pixels, lines, and mouse clicks over the network, not widget descriptions. The result is that RAWT will perform poorly over the public backbone or a slow link just like X11 and VNC -- simply scrolling a scrollbar requires a response from the server.
The other big difference is that XWT is much easier to code in -- you don't have to be a programmer. It's closer to the level of HTML+JS.
Finally, XWT runs as super-fast native code on Linux and Win32. RAWT is still encumbered by the slowness of AWT and JIT JVMs.
RAWT seems really cool though if you already have a Java app that you want to make remote and don't want to use an X Server
Plus, some widgets are different sizes on different platforms (assuming they will use some native widgets). Does that mean the server not only has to query the client for the window size, but also for the size of each widget, only to then tell the client where all the widgets should go?
This is a poor design decision. The client should handle widget positioning.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
so it does what X does.
Gotcha.
How innovative.
I love this idea. I've loved it since the first time I had it in 1988.
But unfortunately, the implementation doesn't appear to work at all with Netscape 4.7.
I'd be willing to run a client program as a plug-in to get this feature. Unfortunately, I can't find any plug-in for this.
-- Terry
www.rebol.com. More stable, faster and better supported
"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.
Howard Stearns - I work at Curl Corporation, but I speak for myself.
This is best done with a component architecture using composition agressively.
That way, the client remains as simple as possible. If you're interested in this, the fresco project wants to do all this and better (and some more).
Gerhard.
(* No disrespect to all the guys pushing php groupware pachages - but it just ain't working. HTML was never meant to do complex things. Hyper TEXT markup language; the world got remote applications and documents severely mixed up. *)
I don't think it is a matter of HTML being limited. HTML is a presentation technology, IOW, for "e-brochures". It does this well, especially for dealing with different screen sizes, if you know how.
But, it is kludgey for business forms and complex GUI interactions. DOM + JavaScript are not the direction needed to fix this limit.
We need a better HTTP- and web-friendly GUI protocol and (hopefully) GUI browser.
HTML is just the wrong tool for the job in many cases. We need to take it's easy deployability, and apply it to better GUI protocols.
HTML is not bad, but taking it where it does not belong is.
Table-ized A.I.
(* [SCGUI has no built-in "flow control" for widget layouts because it is assumed that the server handles such.] That is not a good idea at all. Besides being totally contrary to the goal of "latency-friendlyness" when a window is being resized, it also simplifies the client at the expense of every server, which now has to take care of widget positioning, making them less "simple and stable". *)
In most VB/Delphi/PB-style GUI apps, you usually don't resize windows. Most biz apps are coordinate-based anyhow in my observation, and work better that way. The boss points to exactly where he/she wants something, and you put it there, or are fired. Doing that with flow-based approaches gets us back to HTML-hell. IOW, coordinates are more PHB-friendly IMO.
(* Plus, some widgets are different sizes on different platforms (assuming they will use some native widgets). *)
Perhaps they shouldn't be. This is a sticky topic that can fill many pages. But in general, if you target multiple platforms, then you should leave extra space. I have been thinking about "aspect scaling" to make sure something fits within a given space, at least for text labels. (I talked about this in my 1997 version of the SCGUI draft, but did not in later versions.)
(* This is a poor design decision. The client should handle widget positioning. *)
I am sorry, but I have to disagree. I based my design decisions on my observations, experience, and pondering over a long period of time. There are going to be trade-offs no matter which approach is chosen. I picked the combo I thought would work best without making things too complicated.
Plus, what is wrong with burdening the server? You have more control that way and less things to go wrong on the browser side.
My approach allows both: coordinates by default, but flow-based using the server for the rarer times that one goes that route. You have to optimize a design for the common stuff and find back-up approaches for the rarer stuff. Otherwise, you will end up with a huge, complicated packrat protocol and browser.
I decided that flow-based and resize were too rare to build directly into the client.
Table-ized A.I.
Thanks for the reply. I guess we'll have to agree to disagree. :-)
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....