Thin-Client Applicaton Architectures?
"Leaving aside the backend, the choices for the frontend seem to come down to:
- HTML (and its possible successors)
- Java
- Plug-ins (or other types of browser-like 'universal client' modules)
- HTML is not designed for building traditional data-entry applications, requires all kinds of nastiness to maintain application context, and is inefficient in terms of bandwidth.
- Client-side Java isn't really thin enough by my definition. Run-of-the-mill application programmers shouldn't need to be writing GUI code at all (too damn complex). And then there is the (MS sponsored) murder of the portability promise.
- Plug-ins work well, if you're willing to accept the initial download (and occasional updates), but as platforms proliferate, it's not practical to support them all. A Java-based plug-in might work if only the portable GUI promise were really true.
What this world needs is a good, really smart, dumb terminal.
I've been at work on just such a thing for several years now, and while it's not general-purpose enough to fit the bill, the thing works great. It essentially distills down the N most frequently used GUI features and 'implements them for you'. A simple API on the server lets transaction-based apps talk to the terminal and maintain context easily.
Is it possible at this late stage for a new universal front end to emerge for building server-based applications? And become a standard? Do you think the open-source effect would help? Or am I nuts, and HTML/Java is all you need?"
A curious thing happened on my way to Freshmeat.
Where the hell did Mindbright come from?
Mindbright, for those who don't know, makes the GPL'd Mindterm java applet. It's an incredible SSH client written in 100% Portable Java and has completely changed my perceptions of what a quality Java applet can do.
Suddenly, I have a SSH client at any web browser I sit at. And it's fast, to boot.
If that wasn't enough to impress me, MindVNC is a merge of their SSH classes and the GPL VNC Java client. (VNC is essentially a remote frame buffer--the display is rendered or copied into a virtual screen then sent over the network.) You authenticate against the ssh server that hosts the Java app, and you can VNC to any terminal the remote sshd can access--yes, this means you can connect to your bastion IP Masqing host, then VNC to some 10.* machine behind the firewall, all through a secure link.
The relevance to the story is in simple and speedy deployment of tools--any and every machine with a Java VM can immediately and securely access both text and X based applications with minimal deployment pain. This exceedingly low pain for large scale client deployment via Java may actually benefit VNC in surprisingly powerful ways. Since the VNC system has been ported all over the place, from svgalib linux to windows, and as it poses an open source, well tested, very portable, and highly functional remote access platform, it may just end up becoming a formidable force as the years go on.
Those who don't think projects should be allowed to fork--at all--need to see the amazing work that Mindbright's been allowed to do on the shoulders of the GPL. (The analogue to scientific development wasn't accidental.) More work is left to be done--the Mindterm client could use telnet support, and VNC could seriously use a "single app" mode that sizes the desktop to that exact size of the remote application, translating resizings on the client to resize attempts on the remote app.
The seed of possibility is definitely there, though.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com