Some new idea for a project that came from a problem I encountered at work.
A client uses our web-application at remote sales-points. By remote I really mean remote. The connection is via a X25-line with some 40kbps (bits not bytes!) and a significant latency. We did some tweaking on the Apache to set Expiry and compression so that we have now reasonable response-times.
So far so good. Or not? We had been thinking of moving to an Applet or even a WebStart application instead of a browser based solution. Browser is not browser, for example we had a mysterious bug with IE and Apache when a cached paged tried to load a non-existent JS-resource - the HTML-response got inserted …
Our main goal is to use the same codebase for the applet/webstart as for the server, which will allow more efficient testing and debugging and also avoid duplicate implementations of functionality once in Java once in JS.
At FJA we had an Applet-client which was a bit problematic because it virtually refreshed itself after each keystroke. Our current application has a different approach that minimizes the number of communications. Though this seems nice, it causes long delays on transitions in the workflow and besides that it makes the data-exchange between client and server very complicated.
Ajax is not really an option perhaps, since we have quite complex rules and many inderdepencies in our UI - the management code we have right now is perhaps already beyond the limit of complexity we can handle, since its JS; we need either other developers who can cope with JS-projects having >200kloc or we put it into something “engineerable” - like Java.
But the communication problem persists. Having simpler exchange means having more frequent communications and there is for sure some lower bound for the mean bandwidth we need. As I had a look at X11 today (a collegue needed to do some debugging on a remote Linux-box) I remembered this as very efficient way for remoting and this brought me to the idea of a XApplet.
XApplet is some Swing wrapper that can smoothly switch between an X11-terminal mode and native processing. This means that the client runs either as an ordinary Applet on the client or that it just provides some Terminal-facilities that exchanges tiny messages like key-strokes and mouse movements to an Applet running on the server. Perhaps the full client can have regions of terminal and native components (given they are sufficintly independent).
What is the benefit of a terminal-mode, you might ask? The terminal-mode can easily implement some “asynchronous” behavior and the bandwidth usage is quite evenly distributed. Software like Citrix (and within some limits Window’s Remote Desktop) have proven to be well functioning remoting tools in low-bandwidth environments. When you think of a typical mobile application this approach is perhaps not so bad…