1.1 What are XWT's limitations? What applications couldn't you build using XWT?
1.2 Why is there a translucent band with a picture of a lock
across the corner of all of XWT's windows?
1.3 What technologies inspired XWT?
1.4 XWT needs to run as a trusted Applet/ActiveX control -- how do I know that it's safe and secure?
1.5 On the front page you said the XWT Engine was around 500kb, but the ActiveX control is 1.5MB!
1.6 Why can't I use the tab key and arrow keys to navigate dialogs?
1.7 Why should I use XWT instead of writing a Swing Java Applet that uses SOAP/XML-RPC?
1.8 What other technologies are similar to XWT?
1.9 What's that faint image in the lower-left hand corner of the splash screen?
1.10 How do I deploy an XWT application on an intranet that isn't connected to the Internet?
1.11 Can I customize XWT's splash screen?
1.12 Does XWT support proxies? How does it detect my proxy settings?
1.13 What platforms does XWT support?
2.1 Why aren't tabs allowed in .xwt files?
2.2 Does XWT have any UI guidelines?
2.3 Is there an XWT Specification?
2.4 Why is there no way for a box to get a reference to its parent?
2.5 How do I interface XWT to custom hardware, like barcode scanners?
2.6 Can I run my own launcher, like launch.xwt.org?
2.7 How should I name the .xwt's inside my .xwar archive?
2.8 How can I have the server asynchronously notify an XWT application?
2.9 When using XML-RPC with HTTP Basic Authentication, why isn't XWT sending an Authenticate header?
2.10 How can an XWT application print documents on a printer?
2.11 Is there any documentation on how to use the XWT widgets?
2.12 Why aren't imports scanned when setting the image attribute from ECMAScript code?
3.1 What is XWT's license?
3.2 Won't the GPL infect me and ruin my business!?
3.3 Why do you say that XWT is "nearly complete"?
3.4 What should I know before contributing patches?
3.5 Why are all the lines so long in the source code?
3.6 What build platforms do you support?
3.7 XWT is written in Java -- does it use Swing? Does it use AWT?
4.1 Why are XWT applications delivered in source code form
(like HTML) instead of a compiled form (like Macromedia Flash)?
4.2 Why is XWT cooperatively multitasked? Isn't cooperative multitasking a bad idea (as in MacOS 9)?
4.3 XWT is evil because it can't be indexed by search engines!
4.4 Isn't this just a retreat to the old 1970's model of computing where an elite priesthood
runs the central mainframe?
4.5 Why is it so important to separate an application's UI from its core logic?
4.6 Why do you think the computing world needs something like XWT?
4.7 Why did you choose Java?
4.8 Why is all XWT communication procedure-call based and HTTP-driven?
4.9 Will XWT ever support efficient server-to-client asynchronous messages?
4.10 Can I link some sort of libxwt to my application?
5.1 Why does jdk1.4 occasionally throw an Error (StreamDecoder.java:417)?
5.2 Why does my SSL-protected xmlrpc call fail?
5.3 I can't launch using Netscape
Navigator 4.X from behind a proxy!
5.4 What do you think of Open Source?
5.5 Yeah, but don't you have some pent-up highly political rant about
Open Source, Microsoft, and how geeks are going to take over the world?
Right now, XWT's two biggest limitations are lack of vector graphics and lack of sound. Both should be provided in version 1.1 (using SVG and Streaming Ogg Vorbis, respectively).
We believe that XWT will be usable for a huge class of applications -- spreadsheets, word processors, email clients, and chat clients. We're even developing a web browser on top of XWT, and getting some really impressive rendering performance by taking advantage of XWT's already-highly-optimized box layout and rendering routines.
With that said, there are two major classes of applications which do not work well as XWT applications: multimedia video applications and video games.
Keep in mind that the biggest difference between an XWT application and a conventional application is that XWT has a bottleneck (the network) between the UI and the application logic. Fortunately, only data which comes from the user or is eventually shown to the user must cross that bottleneck. Since humans can't type or read very fast, and static images aren't very big, the only applications that don't work well are those involving large, rapidly changing images (ie live video or 3D-accelerated video games).
Since an average DSL connection can stream Ogg Vorbis at full CD quality, audio doesn't present the same problem that video does.
XWT allows authors to create more visually rich web interfaces than ever before. Unfortunately, with that power comes a danger -- malicious authors can create windows that look just like operating system windows, including password dialogs. A user could easily be tricked into typing his password into such a dialog, and it would get sent back to the malicious author. To prevent this, XWT "scars" all its windows with a stripe and a lock. There is no way for an application author to remove this scar.
In the future, XWT will offer a facility for applications which use only HTTPS (and never use HTTP) to change the image to a closed lock, indicating that the window is not part of the operating system, but that anything entered into it will be encrypted before being sent across the network.
Mozilla's XUL/XPFE
XWT was directly inspired by Mozilla's XUL technology, which lets
you mark up a user interface using XML. I like to think of XWT as
"XUL light with SOAP and XMLRPC", since it is much simpler and
more lightweight than XUL, although it is less powerful than XUL
since it lacks the ability to render arbitrary XML documents. A
brief way of summarizing the differences would be that Mozilla/XUL
sees GUIs as nothing more than a particular kind of document; XWT
sees documents as nothing more than a particular kind of
GUI. Conventional GUI frameworks see both as nothing more than a
grid of pixels.
Macromedia Flash
While working for Reactivity, I did a contract for the now-defunct
contact.com. We wrote a full-blown contact manager / address book
entirely in Flash, which talked to a J2EE/Apache/Oracle server
using HTTP POST (SOAP/XML-RPC were not yet mature). After leaving
Reactivity, I spent a lot of time thinking about that project --
Flash was the best tool available for the job at the time, but yet
was clearly far from ideal. I really wish that we had had XWT back
then.
TeX
Donald Knuth's TeX was the first serious software typesetting
solution, and its rendering model (hboxes and vboxes) shows
unimaginable forethought. XWT's rendering model is directly based
on TeX's.
UNIX
The UNIX model of "many small composable tools" was a major design
influence; you could say that XWT's template data abstraction
requirements are an attempt to impose the UNIX worldview the GUI
design process.
Others
XWT's extensibility framework is patterned after Emacs'. The PalmOS
mentality of "small and simple are good" was another strong
influence.
Well, for one, you can read the source code!
Additionally, 99% of XWT is written in Java, which is not vulnerable to buffer overflows (the source of the vast majority of security breaches), even when compiled into native code using GCJ. The remaining 1% is very carefully audited before signing.
Also, since XWT never writes files to your hard drive (except a logfile on Win32, which is opened before any source files are loaded), "escape attacks" (utilizing ".." to walk up a directory tree) are unlikely.
All .xwt source files are run in an extremely restrictive sandbox; they cannot access your hard drive, and cannot circumvent your firewall since the only network operations they can perform are XML-RPC and SOAP calls to non-firewalled adresses (ie addresses outside of 10.x.x.x and 192.168.x.x). Any windows created by XWT files are scarred; see the corresponding FAQ entry
Finally, the binaries distributed on this site are digitally signed by Adam Megacz, using his Thawte-issued code signing certificate. This means that if it was ever determined that Adam had deliberately enclosed malicious code in XWT, you'd have a pretty airtight lawsuit against him. This is a rather strong incentive for Adam to make sure that XWT doesn't do anything malicious.
We plan to eventually include an entire FAQ on security.
Yes, I fibbed a bit. GCJ (the GNU java-to-native-code ahead-of-time compiler) is a remarkable tool, but unfortunately it lacks the logic to strip out unused parts of a program when compiling it. As a result, there's at least a megabyte of unused code in the Win32 ActiveX control edition. We're working with the GCJ people to resolve this quickly.
You are using an out of date version of the widget set. Either get the latest version from the demo or get the development versions from XWT CVS.
The following technologies approach the same problem that XWT tries to solve, though they do so in a different way. XWT is set apart by its unique status as a zero-install, sandboxed, standards-based solution.
The following companies seem to have a similar product, but don't offer a public demo, so this couldn't be verified: Digital Harbor, Fourbit Fablets
If you know of any others, please let me know.
Please don't ask me to compare XWT to any of these technologies; I am (obviously) extremely biased.
It's a watermark of one cell of the periodic table of the elements. Instead of version numbers (like 1.0) XWT releases are named after the elements, in atomic order. The first release of XWT was Hydrogen, the second will be Helium, and so on. The watermark in the corner of the splash screen lets you know what version you're using.
There are several ways to achieve this:
xwt.exe http://some.intranet.server/path/to/your.xwar
java -jar xwt.jar http://some.intranet.server/path/to/your.xwar
These technique will allow you to deploy XWT applications on local intranets which do not have access to xwt.org and launch.xwt.org. PLEASE NOTE that when using a statically installed engine, you will not get automatic upgrades, as users of launch.xwt.org do.
If the web server holding your xwar is accessible from the Internet, mobile users (those outside the office) can access the same application simply by clicking on the following URL:
http://launch.xwt.org/stable/some.extranet.server/path/to/your.xwar
This gives you the best of both worlds -- your intranet applications are accessible even if your Internet connection fails, yet mobile users can still access your applications from any machine anywhere in the world, without installing additional software.
The XWT startup consists of two phases: downloading the xwar and instantiating the xwar. During the first phase, the XWT splash screen is displayed. Starting with XWT Lithium, if your xwar contains an image called splash.png, it will be displayed as the splash screen during the second phase of the startup. Your image should be 394x276; if it is not, it will be scaled to that size.
Please do not post to the mailing list asking for a way to remove the XWT splash screen. There are plenty of popular software programs out there with splash screens that you cannot remove or alter (Microsoft Word, Adobe Acrobat, Netscape Navigator); XWT is no different.
XWT will attempt to detect your proxy using the following four mechanisms, in this order:
Java Plugin Proxy Settings
If you are using any browser other than Internet Explorer, or you are using Internet Explorer on an OS other than Windows, XWT will query the host browser for proxy setting and use them.
Note: Sun's mechanism for retrieving proxy settings is undocmented and incomplete; thus, XWT cannot retrieve the complete Proxy Autoconfiguration Script -- it can only ask for the browser to evaluate the script on a single URL. Because of this, XWT will check what proxy settings your browser uses to access www.xwt.org, and use those proxy settings for all network transactions. Furthermore, a bug in the Java 1.4 plugin prevents XWT from working behind SOCKS proxies when launched from the Java Plugin. The Java 1.3 plugin is not affected.
Environment Variables
If present, XWT will use the http_proxy, socks_proxy, https_proxy, and no_proxy environment variables to determine your proxy settings.
Note: due to a bug in Sun's JVM, these environment variables will not be checked if XWT is being run inside a Java JVM (non-native code engine) on Windows using jdk1.2 or jdk1.3. Java 1.4 does not have this bug.
Internet Explorer Registry Settings [Win32 only]
If you are using Windows, XWT will retrieve your proxy settings from Internet Explorer's registry settings.
Web Proxy Auto Discovery (WPAD)
If your network supports Web Proxy Auto Discovery [RFC 3040], XWT will attempt to use it to detect your proxy settings. Please note that XWT is not vulnerable to the severe security flaw in Internet Explorer 5's WPAD code.
XWT runs as native code on Linux/i86 and Win32/i86 (95, 98, ME, NT, 2k, XP). XWT will run on any other platform with a Java 1.2+ JVM.
XWT can launch automatically from the following browsers:
Jamie Zawinski explains it better than I can. He also includes instructions for getting emacs and vi to output four spaces (instead of a tab) when you press the "tab" key.
Basically it comes down to two things: There is nothing you can do with tabs that you can't do with spaces, and sequences like [tab][space][space][space][space][tab] get interpreted differently when viewed through different editors. The only way to make sure that everybody sees the same thing is to mandate that tabs never appear in files.
No; anything we published would fall out of date too quickly. The only recommendation we make is to leave window size/position up to the user -- don't try to force anything on them. You should look to the widget library you choose for UI guidelines
No, and there are no plans to write one.
First, a few definitions. A specification is a document from which you could write a compatible implementation. A reference is a detailed description of how an implementation works, but is not enough information to implement a compatible clone. So, for example, Perl has no specification, but it has several references. The same goes for GTK and the Microsoft Windows API.
Like Perl, GTK, and the Win32 API, XWT has a single implementation and a reference. Since the implementation is open source, it can easily be ported to other platforms; hence, the need for a specification (in order to reimplement XWT) is greatly lessened.
For two reasons:
If you're using XWT Helium (or newer), you can use the function xwt.newBrowserWindow(url) to open a new browser window. Pass the URL of a platform-specific binary (such as a Win32 .exe) as the argument. Then tell your users to click "run" instead of "save".
The binary you supply should act as an XML-RPC server, accepting connections only from 127.0.0.1 (for security). Once the user clicks "run", your XWT application can make calls to the binary (using xwt.xmlrpc("http://localhost:someport/"). The platform-specific binary can then talk to whatever custom hardware you're using, acting as an intermediary between it and XWT.
Yes, you can. There are three possible approaches: as a servlet, as a standalone HTTP server, or as a CGI executable.
The launcher sources are available in CVS, and you can pick up the XWT Quick-Start Kit, which includes a fully self-configuring launcher that you can drop into any servlet container of your liking. It also includes a sample xmlrpc servlet and XWT application that uses it; source for these is in CVS with the launcher.
Note that you will have to keep updated on the launcher and engines from dist.xwt.org. By sticking to the official launcher, you get bug fixes and security updates automatically.
If you want to use Tomcat in combination with IIS to run the launcher, see the Tomcat IIS HowTo.
Another option is to run the launcher from the embedded http server in the launcher jar. This can be started by:
java -jar launcher.jar -port <portnumber>
and then use http://<yourmachine>:<portnumber>/.... as the launcher URL.
If you have no other option, you can run the launcher as a CGI executable. This will be inefficient, although the launcher is rarely the bottleneck in any system.
If you are using Windows, you should configure your web server to invoke the CGI as:
javaw.exe -jar launcher.jar
Note: do not use JRE 1.2 on Windows.
On all other OSes, use:
java -jar launcher.jar
If you want to host your own binaries, you should add -Dlauncher.binaries=http://where/to/find/your/binaries to the command line.
Technically, you can name your .xwt files however you like. However, you should abide by the following rules -- if you do not, you will have problems using themes and integrating your application with code written by other people.
Currently, there are three solutions to this problem:
For the future, two different approaches are being considered.
Many XML-RPC server implementations have a broken implementation of Basic Authentication.
XML-RPC runs over HTTP. Authentication is handled at the HTTP layer. The HTTP spec clearly states that a server MUST return a 401 Unauthorized when a client requests a resource which requires authorization, yet has not presented a valid Authorization header. Many XML-RPC servers fail to return a 401, instead returning a 200 with a fault.
The client needs the 401 (and enclosed WWW-Authenticate header) in order to know the authentication realm, authentication type, and digest nonce it should use while authenticating. Without this information, secure authentication is impossible. A client cannot assume Basic authentication, since that would cause it to send the user's password in the clear even when communicating with Digest-capable servers -- a massive security hole.
The following XML-RPC server libraries are known to have this flaw:
Use xwt.newBrowserWindow() to spawn a web browser. The URL passed to this function should be a server-side script that dynamically generates the document required, either as HTML, or as an embedded PDF document. The enclosing HTML document should include the javascript window.print(), which will display the browser's print dialog. This affords the user single-click print access, with the browser acting as a "print preview".
Providing unrestricted access to the user's printer would be a security risk -- imagine an untrusted XWT app secretly starting a print job consisting of 10,000 pages of solid black. If the printer is in another room, the user wouldn't know what had happened until the printer's toner cartridge and paper tray had been completely emptied.
Not yet. However, once you work through the tutorial and read the reference, you can download demo.xwar and unpack it (it's a zip archive); the files inside will demonstrate how to use the standard widget set. You should start with org/xwt/demo/main.xwt. Also, the source files for each widget have simple usage instructions at the top of the file.
Please refer to this message to xwt-dev.
XWT's licensing is covered on the License page.
No. You should stop listening to Craig Mundie and his fearmongering FUD-slinging.
Please see the previous question; if you develop applications that run on top of XWT, you are free to license them however you like.
Most successful platforms reach a state of maturity early. Donald Knuth wrote TeX and released it with version numbers asymptotically approaching Pi. The Java JVM/bytecode spec hasn't changed since version 1.1 (and changed very, very little between 1.0 and 1.1). This is important because it gives downstream authors a fixed target to code for. HTML and the web in general suffered greatly in the mid-90's from the constant changes and proprietary extensions to the HTML spec. I'd rather not see that happen to XWT.
Following the Java model, I strongly believe that it's important for the base XWT engine to be simple, and to become mature and stable very rapidly. By keeping the XWT engine both simple and highly general, we allow continued evolution to take place in the standard widget library. This closely parallels the Java model, where the JVM was essentially complete at version 1.0, yet the class libraries have substantially expanded Java's capabilities with each new release.
At this point, there are really only three major features missing from XWT: the ability to render vector graphics (by embedding SVG), the ability to apply arbitrary raster filters (like photoshop) to boxes, and the ability to stream audio (ogg vorbis format) to the client. I expect to include all of these features in XWT 1.1, at which point the client will be essentially "complete", and futher work will be focused on server-side features and better widget libraries.
Patches and submissions to the XWT Widget Library (.xwt files) are always encouraged and generally accepted with a very little trouble. All submissions to the widget library must be licensed under the LGPL in order to be accepted. The author retains the copyright on such submissions.
To submit a patch, please email the output of "cvs diff -u" to patches@xwt.org. If you have created a new file, please request that a "cvs add" be performed before you produce your patch.
Submitting patches to the engine (.java files) is generally discouraged for the following reasons:
There is one exception -- if you're porting to a platform that was previously unsupported, and you confine your changes to a single pair .java file in org/xwt/plat/ (and possibly also a .cc file), the standard is much lower, since buggy support is better than none at all. You may also retain the copyright on the code, provided that you place it under the LGPL.
If you've read this, and you still really feel that submitting a patch to the engine is a good idea, please post to core@xwt.org before you begin development. This will avoid wasted effort if there is a consensus that your patch would add more bloat than benefit, or would compromise portability.
80 characters was the standard back when everybody was coding on VT100's. Now, 1600x1200 displays are common. Even on my 1024x768 IBM Thinkpad X20 which I used to write XWT, I can easily get 150 characters across an xterm.
Using horizontal space makes it easy to arrange your code in "paragraphs", putting extra whitespace between logically separated chunks. It also lets you compress trivial "glue" code (like "int getFoo() { return foo; }") into a very small number of lines, allowing vertical space to signal the complexity level of the code -- complex, tricky algorithms get spaced out a lot (into many "paragraphs"), while glue code gets crammed into a tiny block, shoved away in the corner since its structure is already obvious.
On top of it all, I don't have such a great short-term memory. I like to be able to see not only the function I'm working on, but the two or three others that it interacts with -- all on the screen at the same time, to minimize scrolling.
While XWT targets many platforms already (Linux, Solaris, Win32, MacOSX) and we are agressively expanding that list, we only support GNU/Linux as a build platform. This is mainly because GNU/Linux is freely available, widely understood, simple to install, and runs on just about any piece of hardware on earth.
It is much easier for new developers to throw Linux on a spare partition/machine than it is for us to make our build process OS-agnostic, and to spend time resolving conflicts when one developer checks in changes that break the build on an architecture he doesn't have access to.
Furthermore, we don't anticipate that many people actually building binaries -- most of the work that needs to be done revolves around developing the widget library.
Adam Megacz is a Debian bigot, although the build instructions should work on just about any major Linux distribution.
XWT does not use Swing. XWT only uses AWT when it is running inside a JVM. When compiled into a platform-specific binary with gcj, it uses native methods to access the host OS's graphics routines directly.
AWT is abstracted away with the org.xwt.Picture, org.xwt.Surface, and org.xwt.DoubleBuffer classes. The only AWT classes/methods used are Image, Font, Frame, Window, Graphics.fillRect(), Graphics.drawString(), and Graphics.drawImage().
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 .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).
Fortunately, XWT allows you to keep most of your application logic on a server, and only distribute the user interface. This is advantageous, since it forces service providers to disclose enough information for third parties to automate or script those services, while protecting the service provider from having their intellectual property stolen, since it is never sent to the user (not even in binary format).
However, probably the biggest reason for the choice of a source-exposed format is what we learned from HTML. HTML and the Web flourished because you could look at other peoples' HTML, and learn from how they did it. If you saw a cool trick on somebody else's website, you could "view source" and learn how it was done. Without this learnability, the web probably would have been no more successful than source-obscured formats like Macromedia Flash, Adobe Acrobat, or Shockwave (which are all successful, to be sure, but still not even in the same league as HTML).
True, cooperative multitasking is a bad way to build general applications.
However, XWT is only used for building user interfaces, not general applications. This means that XWT applications cannot perform I/O (aside from XMLRPC/SOAP calls, which are the only part of XWT which is preemptively multitasked), nor are XWT user interfaces intended for performing long-running computations.
Because the set of things which an XWT UI must do is so restricted, we can safely make the assumption that no operation will take more than a few milliseconds. Furthermore, we can partially enforce this requirement by simply not providing any blocking constructs (semaphores, mutexes, I/O) in XWT. The only way to "hang" an XWT application is to go into an infinite or long-running loop.
The advantage of this cooperative model is that it vastly simplifies the programming experience. XWT authors don't need to undertstand synchronization, condition variables, monitors, queues, semaphores, race conditions, or deadlocks. Furthermore, authors can do sophisticated multithreaded programming without worrying about concurrency issues -- it is always safe to assume that your thread has the full attention of the CPU.
One final note -- XWT does provide threads, although they are cooperatively multiasked. And it does provide one blocking operation -- the XMLRPC/SOAP call operator. When an XWT application makes an XMLRPC/SOAP call, it blocks (and yields control of the CPU) until the call returns. For this reason, XMLRPC/SOAP calls cannot be made from the foreground (event-dispatch / rendering) thread -- you must spawn a background thread to make the call. This has a positive side effect -- XWT applications will never exhibit the "stuck and won't render" problem that is common in Win32/X11 applications, where an application locks up and refuses to repaint dirtied regions.
To conclude, it is only because of XWT's strict separation of user interface from application logic that it is able to get away with a cooperatively multitasked model. Fortunately, that model brings major simplifications to the development process.
Yes, but <form>-based web applications (which is what XWT replaces) can't be indexed either.
HTML and the web are a fantastic technology for distributing documents. HTML forms started out as a simple way to query an archive of documents, but were rapidly pressed into service as a full-blown interactivity engine. This is a task for which forms are a horrible choice.
XWT is useful anywhere you have an HTML form that does more than search an archive of documents. Very soon, we will have a full HTML rendering engine that runs inside XWT, meaning that you can pull HTML documents into XWT. If those documents live on an HTTP server, they will still get indexed by search engines.
True, just like the mainframe model, XWT allows centralized administration of computing resources. But that wasn't the main problem with the 1970's mainframe model. Back in the 1970's, you had just one choice of which mainframe to use -- the one that your organization owned. Now that we have an Internet, you can choose from a wide array of competing software providers.
For commercial projects, the importance is clear -- the people who design UIs (usability experts) and the people who write application logic (programmers) are not the same group of people. The more you entwine their jobs, the more time they waste in meetings. By cleanly separating these two tasks, you let each group avoid stepping on the other's toes.
For open source projects, the reasons are different. To borrow some terminology from The Cathedral and the Bazaar, separation is important because user interface design is fundamentally a cathedral task. You can't subdivide the user interface and say "ok, Max will design the File menu, and Joe will design the right-click context menu", since you'll never get a consistent, learnable UI that way. XWT's separation means that application logic can continue to be developed bazaar style, while several UI designers can compete (cathedral-style) to create the best UI. And the best part is that there doesn't have to be a single winner -- XWT gives you "pluggable UIs" automatically.
Finally, both camps benefit from the scriptability that XWT brings. Since there is a sharp separation between the UI and application logic, third parties can easily script the application logic by connecting to it and pretending to be a UI.
Most people don't want the hassle of being administrator for their own computing resources (installing, upgrading, patching, fixing security issues, resolving system conflicts, etc). As software gets more complex, this hassle will only get worse.
Microsoft recognizes this problem, and they are trying to solve it by making Windows smarter, and by automating system maintenance tasks. This strategy has limitations, though. If it really were possible to replace system administrators with software, do you think that the Fortune 500 would keep spending money on six-figure salaries for IT personell? The answer is that software self-administration can be successful for simple applications, where users never stray very far from the common, well-known test cases that Microsoft's QA labs are able to reproduce. However, we believe that XWT will enable unsophisticated users to interact with applications vastly more complex than anything that could be supported by the software-self-administration approach.
Portability. With HotSpot on four platforms (MacOS X, Win32, Linux, Solaris) and special purpose tools to compile Java for other platforms (Jump2 for PalmOS, GCJ for just about everything else), Java was a no-brainer as the quickest way to make XWT run on everything.
Security was also a big factor; it's really, really nice to not have to worry about buffer overflows.
Serializability
Unlike most programming environments such as Java and .NET, XWT
has the property that no script can ever make a nonserializable
object (such as Java's java.net.Socket, java.lang.Thread,
java.awt.Window, or java.lang.Class). This means that at any time,
the entire state of an XWT app can be serialized and
shipped back to the server to be restored later, without requiring
any additional effort from the application developer. By
limiting network connectivity to procedure-call based
transactions, this property is maintained. If long-lived socket
connections were allowed, XWT apps would not be serializable,
because open sockets cannot be serialized.
Proxy Compatability
Those of us fortunate enough to have packet-level access to the
Network often forget that most of the world is trapped behind a
corporate proxy. For those people, HTTP is All There Is. To ensure
that XWT works for these people, and, more importantly, to ensure
that all XWT apps are guaranteed to work in all environments, XWT
does not implement any network primitive which would not work
through a proxy.
Server-to-client notifications in XWT are done by polling the server. Two enhancements are planned for future releases to make this more efficient:
HTTP Pipelining
For efficiency, future versions of XWT will implement HTTP
Pipelining (RFC 2616,
Section 8.1.2.2). This lowers the cost of polling to a single
packet per polling request. Multiple in-flight polling requests
can be used to lower the polling latency to RTT/2, which is what
the latency would be even if full server-to-client asynchronous
notifications were supported.
Long Term
However, just because XWT uses procedure-call semantics at the
lowest levels does not mean that developers are stuck with this
API. Future versions of XWT will include native support for
Jabber-RPC, allowing XWT scripts to recieve asynchronous Jabber
messages from servers. To ensure proxy compatability and
serializability, however, the Jabber implementation will use HTTP
polling to retrieve messages.
No. XWT is a platform, not a library.
The main reason we haven't gone down this path is that it would encourage people to write application-specific xwars -- xwars that only work with a certain application. It would also encourage people to write xwars that are not network-transparent (ie must run on the same machine as the application logic). In order to prevent this, the only way to get information into and out of the XWT engine is via XML-RPC and SOAP.
There are also other complications. First of all, the XWT engine is GPLed; linking against it in this fashion would necessitate GPLing your application. Secondly, XWT uses libgcj and the boehm garbage collector, which make certain assumptions about "owning" the entire process they run in. Neither of these complications is fatal, however, but we feel that our resources would be better spent elsewhere.
However, you can achieve the same effect. You can have your application spawn a seperate process and run XWT in that process. The XWT application can then make XML-RPC calls to the special URL stdio://, which treats stdin and stdout as a socket, and makes XML-RPC calls over it. The parent process can redirect these streams and use them to communicate with XWT. Finally, certain platforms support special command line options that instruct XWT to draw on specific surfaces (for example, under X11, you can pass the numeric window-id that XWT should draw on).
This is a known bug in Java 1.4. Please encourage Sun to fix it.
When making an SSL-protected xmlrpc or soap call, it may sometimes fail, putting an entry like:
TinySSL$SSLInputStre: got Server Certificate(s)
ThreadMessage: caught throwable at thread entry point; this should never happen
in your logfile (windows) or Java console (just about anything else). What this means is that:
OK, first of all, please upgrade. Netscape has release two new major versions of their browser suite since the last 4.X, and 4.X is now 'mature', to use their terminology, which means that the only support you're going to get from them is advice to upgrade to 6.21 or higher. Netscape 4.X is dead, 'mkay?
Anyhow, the default setup of Netscape Navigator 4.X behind a proxy
will not, by default serve applets well. You can work around it
by adding the following to your prefs.js (for each separate user,
I'm afraid) while Netscape is not running (mail, browser,
editor, etc must all be closed):
user_pref("signed.applets.codebase_principal_support",true);
user_pref("security.lower_java_network_security_by_trusting_proxies",true);
See also Security
preferences for Communicator from netscape.
Or you could just upgrade.
I mainly think people should stop wasting time pontificating and philosophizing about open source and just write some good code.
My primary goal is to have a substantial, positive impact on the state of the art, and giving my code away for free is simply the fastest, easiest way for me to achieve this objective.
I use the term "open source" to describe the licensing terms of my code, not my political agenda.
If I haven't made it clear already, I don't get into the napoleonic aspects of open source. I use GNU/Linux/Apache/GCJ/Rhino because for my specific needs, they are undoubtedly the best tools available -- not because I think that commercial software is somehow impure or wrong.
That said, I've always seen Microsoft, Startups, and Open Source as three snakes, each eating the next's tail. The Silicon Valley startups, driven by enlightened greed, come up with crazy, inventive new technologies. A few years later, Microsoft either buys out the startup or bundles a copy of its technology into the Windows Monopoly and puts the startup out of business. A few years after that, somebody completes an open source program with a crappy UI and a better implementation of all the features that Microsoft just finished bundling into the OS. And a few years after that, a new startup running out of a garage, strapped for cash, discovers that they can modify this cool open source program to do something new and interesting, or build on top of it, and they create a successful business. And then the cycle repeats itself.
Like I said, quit whining and go write code. This is the way of the world; just keep the snakes moving and everybody gets cool new stuff. Got it?
<%@ include file="suffix.html" %>