Thin-Client Applicaton Architectures?

Rob writes "This is a pretty broad question, but I'm in the process of evaluating alternatives for thin-client application platforms, and could use some insight into what's likely to emerge as next-generation standards over the next few years." There's more meat to this question. Click below for more.

"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)

Here are the problems I see with these choices:

• 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.

My conclusion (and please count to 10 before flaming):

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?"

Comments

There's a good chance

[Bruce Perens]

If you build it, they will come. :-)

Put it out there in Open Source and see what happens. Build a trademark-based certification program so that it can remain Open Source and have strong standards at the same time.

I agree with you that Java is fat. I'm not sure the "dumb terminal" is the right approach, though. Modern applications, for example word processors, need to do a lot of computation per event, and that is best done locally. I think Guido's use of Python, rather than Java, as a thin client language was a good approach and it's too bad it got buried in the Java hype. So, perhaps an Open Source lightweight widget kit plus an Open Source language would be better. But I'm not discounting your idea - it sounds like NAPLPS for the 2000s, but maybe the world needs a new NAPLPS.

I'd rather have the Open Source world charting the course of think client development, too. Thanks

Bruce

Check out Apache JetSpeed

[burtonator]

Check out Apache JetSpeed (http://java.apache.org/jetspeed)

It is a thin client (HTML 4.0, JavaScript/DHTML, and DOM) that is a Groupware/Portal application.

I think it has what you are looking for and solves all your problems. It doesn't use Java on the frontend but solves the rich-client problem by using DHTML.

Kevin

Thoughts..

[Dacta]

I'm not sure what you want to be answered. Is there room in the market for a thin client application tool? Yes. (IMHO)

If you want my thoughts on current options, read on.

You seem to have decided on the idea of using a browser as a thin client. Is this just an assumption, or is there a good reason for it?

If you want (can) get away from the browser, there are plenty of "thin" client solutions - the question is, how thin do you want it?

Low Bandwidth X (LBX) is a possibility (and is even thinner than HTML), and then there are plenty of non-Standard application generator tools that will do something similar (Under windows, Delphi, VB, Powerbuilder, Oracle Forms), but the "Thin" client for these is "thicker" than HTML or X

Depending on your application, (please, no flames) ActiveX Forms may be suitable, but you seem to not want to go with Java, so I guess the same problems apply with Active X

XML based applications have a lot (as in - I think up new ideas every day) of potential. IE5 does some pretty cool stuff at the moment with XML, and the Mozilla GUI is "written" in XML.

My "Big Idea" (TM) at the moment (I should try for funding *S*) is to write a universal thin client that would use the libGLADE to build a GUI from a XML file delivered by HTTP. The button presses etc would be passed via the thin client framework to event handling code on the server using either CORBA or (my personal favourites) XML-RPC or SOAP

Anyway, there you go. If anyone decides to try coding it, please let me know - I might actually get around to doing some myself. *S*

Mindbright and VNC

[Effugas]

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

An interesting Linux thin-client project

[Farce Pest]

University of Georgia Department of English. Old, throwaway 486s as X terminals, with a central application server. (Disclaimer: not my project)

Use HTML for the forseeable future

[trichard]

I've had run-ins with other thin client architectures including Java, HTML and Citrix Win/MetaFrame/ICA type solutions.

It really depends if your application is in a closed environment such as a corporate intranet, or if it needs universal client compatibility.

In the closed environment, you have a lot more control over the client hardware specs. In this situation, if you can build a case around return on investment you may be able to find some takers.

I think that your best bet, though, is to stick with HTML. There may be some pains in maintaining application context but all in all the form/submit metaphor generally matches well with database access applications. It's really not much different from 3270/5250 type terminals. Furthermore, getting too tricky with GUI elements tends to limit usability rather than enhance it.

Ultimately, if you stick with HTML you'll have the widest range of client devices to choose from. Everything from big, fat, PC workstations to small, skinny, fixed function "internet appliances."

Even PDA's and cell phones become potential clients in this "everything's got a browser" age.

Yes, stick with HTML. Do all the harder stuff at the application tier.

Good Luck!

You want a dumb terminal?

[scrytch]

Try a SunRay1 (aka Corona in many circles). Thin as it gets, they're a framebuffer on ethernet, for the most part. A cheap dumb graphical terminal, your X session runs on the big monster server. One big expensive machine, but only one to manage. Talk about going full-circle, eh? They do have some interesting features. Stick a smartcard into one and log in, and your session follows the card. Yank the card out, and it goes to the login screen. Stick it into another corona box, and your session comes back up. Even the mouse is in the same place. The hardware is all USB, so you can use your favorite USB peripherals, including printers and scanners (it locates and adds them, presumably via Jini). Anyhow, you wouldn't run coronas over a WAN, but then again, ultra-thin clients aren't necessarily the best choice on a WAN either.

BTW, just as a disclosure, I do work for Sun. I personally don't think SunRays are the ultimate solution to desktops, but they're the niftiest dumb terminals I've seen yet.

Citrix

[TheBashar]

I have used and really like Citrix thin client solution. Their Metaframe product works extremely well. Even better, they have been slipping out from Macroshaft's leash lately and announced they are working on Unix (Linux) versions of the Metaframe product. I think you should give them serious consideration.