Slashdot Mirror
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)
- 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?"
The list of possible technologies left out XML. A thin client with a small Java applet for handling XML communication works quite well.
Bloatus Notes??? Gag me!
Outside of some obvious markets like PDAs and appliances, why is there such emphasis on thin client? The computing power, network bandwidth, memory and so on are all rising pretty steeply. With technology like Java (only one of many such) that enables download of objects/classes as needed and competent end-nodes, who cares about thin-clients? What it seems to me is really needed is much more powerful peer-peer object communication and management. Too much thinking gets straight-jacketed into client vs. server.
As a first step, I have a grammar-sensitive JavaScript compressor which I'm releasing into open source.
Seastead this.
Given that you're looking for a forms based solution Java will be fine (although you probably should go with the plug-in). Swing DOES give you a nice cross-platform UI if the AWT proves to be unsatisfactory.
It's VERY easy to write a generic forms engine which generates it's layout from the data definitions. Java's Reflection support makes this that much easier. I don't know if there's a 3rd party package to do this, but I've written my own on several occasions.
sigs are a waste of space
The technology of the future... here today.
X is an excellent protocol; it does every bit of 2D and 3D graphics you could ever want. Servers for it are mature and available, as are X-terminals. LBX (low-bandwidth X) allows you to run it comfortably over long distances and tiny bandwidths. If you want even more compression (plus encryption) you can tunnel it through ssh. Client-side libraries like Motif work perfectly well, and when you're worried about bandwidth, they work perfectly well with LBX and ssh.
Go get some NCD Explora Xterminals, or for that matter, any kind of Xterminal, including crappy PCs with XFree86 on them.
X is already here. Use it. Love it. 'Nuff said.
I agree. In my experience, Citrix is hands down the best thin-client solution, especially in mixed OS environments.
Publishing aps to the web works well, and the java ica clients have worked flawlessly on our linux boxen. Running NT-centric accounting bloatware across ppp lines that run as fast as if they were on the lan. 20k MAX bandwidth. Sweet.
Do you remember RIP terms. they did some simple gui type stuff and were designed to work on 386 class machines and 1200 baud modems. I wonder where that technology is now and if it could be extended to work over TCP/IP.
I think some sort of a universal client is sorely needed. Something stateful, something with a decent GUI, something easy to program, something that would work with any OS. Am I asking for too much or are we perpetually relegated to mixing HTML, Javascript, CF/ASP/PHP code together in files and hope to make something work.
War is necrophilia.
I agree, I've been using Starnet's xwin32 product on poxy old NT connecting to my SVR4 & SCO boxes and having a great old time.
Andrej
Fortunately, we don't have to depend on CORBA for what you're talking about. Why not look into MOSIX to see how this is going to be done? (btw, this funded by VALinux now...)
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
GUIs are the bane of my existence!
At the risk of over simplifying an answer . . .
Yes
I think it's going to be an ugly hodgepodge of broken scripting languages, based on the huge number of ASP pages I'm seeing out there.
Actually, Sun is doing a lot with Java by putting the "VM" in a chip (ergo not so V anymore), then running SSL out to the box in question. It still has a way to go, and the complexity of Java will push the average computer guy back to those nasty scripting languages...
Plugins are out. The entire point to thin client is to stop distributing software to desktops!
The way I'd like to see things go is Lotus Notes/Domino go OpenSource and with clients for anything. Granted it is slow and proprietary, but Exchange and GroupWise can't even approach the same functionality ballpark. Building your own out of Apache and a database is probably possible, but how mucch time would be spent reinventing that wheel?
"Nothing was broken, and it's been fixed." -- Jon Carroll
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
Bruce Perens.
Isn't it ironic that the "thin client" of today is the monster machine of a year ago? Do you really just mean a "not-so-top-of-the-line" closed box that the user can't mess with?
http://kered.org
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
Applix Anyware has a java powered thin client that is smart enought to run dialog boxes, redraw widgets, and do other trivial things without going back to the server. This is exactly what X, not to mention http/html, is missing. Sure would be useful for better freemail clients, among other things.
How about a server with /usr and all the other good directories exported via NFS? Maybe you could even have a directory for each client that has the specifics for that machine.
That way, all you have to do is mount the directories and you have great functionality.
This would make better use of your disk space, since it would be stored centrally, an only part of the boxen would be using disk space at a time.
However, for what the price of memory and processors go for nowadays, I prefer to have that stuff on the client boxen and not on the server, like I understand is the current trend.
Or is this a semi-thin client?
I do what the voices on my console tell me to do.
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*
Why not use it? It's FREE It's WELL supported. It's QUICK It can be run in low bandwidth It VERY portable What more do you want? BTW: Will the QNX floppy work as a usable X server for such a task? I've not tried that yet. It might cost a couple dollars to license it, but you can't get much thinner!
Of course, I could argue, if I'm using Windows then I don't have any valuable data -- but that would be a Troll and it'd be moderated down...
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
I am inclined to stay with HTML even with some of its problems. What we are looking for is a box with no moving parts to get broken, dusty, or fail. No hard drive, no floppy, and no games. It will be on a corp. intranet where everything the users need is HTML or on a 3270 emulation screen. The browser needs a PDF plug-in because we have a lot of content in that format. JavaScript is required and Java is optional for us. I really don't care how thin the network computer is as long as the cost of ownership is low. Low maintenance, security, performance, open standards, and reliability are what's important, not "thinness".
HTML & Java can't do the job. What's more, the typical client/server app would cost 5 times more in HTML & Java than with a typical client/server tool.
Java is a transitional technology that will exist long enough for us the discover why we shouldn't use it, and then disappear, and be replaced by something that works much better.
The revolution of the Internet is not HTML, is not Java, is not XML, or any other misguided and overhyped buzzword. The revolution of the Internet is the connectivity itself that is on its way to become ubiquitous. Everyone can potentially reach anyone, in almost real time. The ways in which we use this connectivity will change and gradually improve over time.
One thing is for sure, the next breakthrough of the size of HTML/http will not come from Microsoft of from Sun. Very simply, because of the way Microsoft and Sun make money, ubiquitous connectivity is a threat to them. If everyone can communicate with anyone else, what would we need them for? The sole reason for existence of Microsoft and Sun is to make sure that we cannot communicate properly without using their products. Their goal is to stand between you and the rest of the world. That's why they will continue to either try to control or else try to destroy the internet.
The next breakthrough will come again from some humble individual or group of individuals like Tim Berners-Lee, who will propose a solution so good that it will take the world by storm again.
This perl versus java thing confuses me. It seems that there are people who truly believe they can do anything with perl.
Perl is a scripting language, Java is a system programming language. Mind experiment: implement java in perl, now implement perl in java which of those two programs do you want to maintain?
Jilles
I am suprised that no one else has mentioned them yet...(maybe I missed someone's comments!..forgive me if I did)
I gather that your goal is to support thin Clients using a simple, common architecture...
Java Servlets combined with HTML/JavaScript and JSP(Java Server Pages) and JSSI(Java Server Side Includes) provide a large amount of power and flexibilty and in my opinion, achieve excellent thin-client support rather nicely.
Further, Servlets are specifically designed to support HTML and the Thin-Client paradigm.
After writing C/C++ CGI database apps, dabbling in Perl with CGI, using Oracle's app server solution, and writing Applets(I detest applets...), I decided that Servlets are SOOOO much better than any other solution.
There are many implementations(Open Source too!) of the Servlet architecture including my favorite: Apache JServ
To give an idea of the capabilities, I have written servlets which allow password/account maintenance in databases, an entire travel agency system, and even a servlet which acts as a fully-enabled SQL client.
One of these days I'll write that telnet servlet...(hehe) I don't remember the location, but somewhere I saw a survey which showed that over 40% of all new Java applications were based on servlets.
Since Java XML intergration/interaction is increasing rapidly, I suspect that Servlets will gain an even larger part of web computing as XML becomes more widely used and accepted.
Im my opinion, Sun should have been pushing Java for the server long ago...and they should stop shoving Linux aside and accept it as the future.
In any case, check out Java Servlets. I don't think you will be disappointed.
Christopher Fitch
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
I think he was referring to the server part. Yes the client does have one or two (!) minor (!) issues.
You must be joking, of course. VNC with a Unix server is better, supports more different clients, is faster and costs nothing vs. thousands of $$$s.
goto www.sun.com/products/sunray1 they cost as low as 200 per box with monitor.
What about http://entity.netidea.com ? Perhaps promising ?
Yes, VNC kicks ass.
:)
No, I don't seriously write in Perl or Java, but...
C is a systems programming language.
sh is a scripting language (shell, yeah! What are you programming in? Shh.).
Java is a Lisp interpreter with C++ syntax beaten with an ugly stick.
Perl can be ugly, but it's at least optimized for a task.
Conclusion? Write in C. Or assembler, if you can. Or anything but BASIC.
---
pb Reply rather than vaguely moderate me.
pb Reply or e-mail; don't vaguely moderate.
Client-side Java isn't really thin ... true in a browser! A complete java desktop, cut loose from netscape or ie remains thin though, look to SevenMountains Software www.sevenmountains.com for a complete implementation of such a desktop, running on any platform with a decent vm, with a stunning performance. Client: 5 megs, browser included.
HTTP thin clients?!?
What browser are you gonna use anyway? You know, you'll need quite a decent machine for most popular choices..
Anyway - your usual Delphi app runs around any browser. Bad thing is that it's for Windoze only now.
Really. The only reason for HTTP based apps are "cross-platformity". Thin? Nah, IMHO.
And calling Java a thin client is a total joke.
Try Linux on IBM's thin clients. They're pretty much like normal PowerPC's only without a harddrive. (Hint: mount root on NFS)
http://www.uk.research.att.com/vnc/index.html What is VNC? - A practical introduction VNC stands for Virtual Network Computing. It is, in essence, a remote display system which allows you to view a computing 'desktop' environment not only on the machine where it is running, but from anywhere on the Internet and from a wide variety of machine architectures.
I have run Citrix's Metaframe Client for Linux to connect to Windows Terminal Server. It's pretty OK and works over a modem link quite satisfactoraly.
However, for me, telnet is the ultimate thin client. It allows me to run ANY text mode program.
Really, Forms aren't so bad. The issues of maintaining application context were solved years ago.
They are well understood, there's an unbelievable number of tools and examples. Bandwidth use, while not entirely minimal, is not that bad, either.
If your concern is presentation, just a little Javascript goes a long way here.
If you are not concerned with presentation, you can actually do a lot with character-cell based forms over a telnet connection. It's a tough sell, but once your users are trained, they typically love the responsiveness and efficiency that can be had with a simple solution like this. Of course, these days, to run a character-cell based form typically means a PC, which is too thick for some.
As others have said, maybe there is a market for a new dumb terminal standard. You might want to try and work out exactly what your ideal dumb terminal would have, but unless you can build commodity hardware, it would probably have to be implemented with HTML, XML, Java or some other plug-in.
Mind experiment: implement java in perl, now implement perl in java which of those two programs do you want to maintain?
Neither, I'd rather use Python!
About a year ago I was working for Tektronix in their thin client devision providing hardware and software support. Since then Tektronix have sold their thin client devision to NCD. I had the time to browse their website and I have found a possible hardware solution for you.
The NCD range of network computers run an embeded OS called NCBridge. This software supports HTML sessions via a local Netscape v4.x browser, a local windows manager (Motif), X11 support and ICA support for Citrix sessions.
The hardware used to be fantastic when Tektronix owned it and I can't really comment on NCD. But I can tell you that this hardware solution when coupled with a sensible server setup of maybe Citrix/NT-TSE and X hosts you could provide the end users with all of the requirements to access any solution you choose to develop for the server side.
The NCD Network Computer model list
NCD Home Page
Things that spit out HTML are GUI code too. They're just writing to a constrained, high-level UI toolkit. The more client-side scripting you add the more you get back to the same old hard problems from traditional low-level AWT/Tk/whatever apps.
For me VNC is one of the possible ways (and currently the only practical) to get Linux/Unix Apps and Servers into all-Windows environments.
....
Its pretty responsive over a lan, somehow usable over an ISDN line (transfering everything as bitmap has a price), and it gets your apps on to a Win-Desktop without disturbing it to much.
While X is the more advanced protocol, all the X Clients for Windows i have seen so far are to complicated to configure, to invasive on the clients desktop and (last but obviously not least) far to expensive for a workstation ad-on.
And with the integrated HTTP-Server and VNC-Client appelt you dont even have to install it on every client.
Just install the Xvnc server with inetd-extensions applied, configure your (x)inetd - and you have you have your 'Personal Desktop Anywhere'
Now, if it only knew about fonts
I'm kinda confused by the whole thin client thing.
:-)
Its possible to buy desktop and laptop machines which have the equivalent of supercomputer processing power. Shortly it will be possible to purchase PDA's with the same amount of power.
Some PDA's now available carry more processing power than a desktop machine I had 5 years ago.
You can buy hard-drives with 22Gb of storage space for under $150.
Browsers suck. You kind of think they're ok until you use a native app doing the same task. Something like IRC is a good case in point. Try using an HTML based IRC client followed by something like Yahoo Messenger (ok its not IRC but similar and is a really NODDY app). The difference is astounding.
Here I am typing into this crummy little text box and marking HTML up by hand, when I could be using a decent HTML word processor. HTML sucks.
And why the hell do people think that XML is some kind of saviour ? Its great as a comms protocol and for marking up data, but it doesn't do anything to solve the problem of creating a really usable UI.
Why doesn't Java work ? Well Java apps are pretty thin if all your UI requirements are on the target machine. But this just doesn't happen. This is exacerbated by browsers not having proper java support as standard - might be slightly better if AOL/Sun get their collective asses into gear and ship the JDK on the AOL CDs.
The thing is, you can say the same for any language. A Java prog. could in principle use just the same elements as the dear old browser, but it sucks doesn't it. It all boils down to Lowest Common Denominator(LCD). Its damn remarkable what people have done with HTML but it doesn't excuse us working with a prehistoric technology.
I think part of the solution is to have a set of common UI controls defined using good old IDL to give language transparency. This would be coupled with a formal mechanism for embedding controls within one another (even if written in different languages). Troll software have gone someway towards this goal with their KOM proposal, and whilst I think the Qt kit is generally very good, it still falls short of the ideal UI toolkit.
The next part of the solution is to define a framework within which the interaction experience can be customized. The original remit of Java and HotJava was to have a completely dynamic browser environment. One in which you could use just plain old HTML if that was all you wanted, but, you could also install extensions to the browser dynamically. Not in the wishy-washy way that applets do it, but true application extensions - things that actually remain installed instead of being loaded every time from the network.
Couple this with proper versioning and a flexible security model (browser sandbox models were far too restrictive) and you start to have the makings of a good solution.
Another part of the puzzle is to continue using some form of connectionless protocol between the client apps and the server - as this would appear to be the only truly scalable solution. There may of course be times when a permanent connection is suitable but those should be few and far between. The connectionless requirement is why the X-term solution doesn't really cut-it. You have to assume that your app may have 10000+ users at any one time.
There has to a realisation that an application's logic should be distributable. That essentially means that you should be able to load balance by choosing either the server or the client for performing compute intensive task. In some cases server side only makes sense, in other client side etc.
Finally, our portable UI toolkit would ideally be scalable, but in reality we have to notice that different form factors have totally different capabilities - and taking the LCD approach is just a cop-out. Classify the types of UI that are possible - Phone, PDA, Sub-Notebook, Desktop, Holodeck - and provide UI's appropriately for all of them. This is why a good decoupling of the UI from the core-logic is essential. Building the UI should be near trivial - but have you noticed how much logic actually goes into making UI's behave sensibly - this really is a fault of the toolkits we use.
There's my tuppence halfpenny
Although you accurately note that HTML is far from ideal, Java servlets can enter into the scene, and, say, take your an XML-defined GUI and map it to HTML on the fly for you. There are also several packages out there that will actually reconstruct the appropriate Java GUI complete with widgets for you in HTML. The servlet would maintain state I'm assuming.
/Java/, which is really nice, and may be able to solve a lot of your problems.
Full-blown Java app. Java does incur some overhead, but the portability really is there as long as you are not doing something really funky or attempting to make use of the latest whiz-bang features out of Sun. We deploy Java apps to a campus of over 30,000 people, which is also pretty heterogenous (Windows, Mac OS, Linux).
As for plugins, I would trust them as far as I can throw the bloated browsers out there today. But take note of Mozilla. When it comes to fruition you will be able to write pluglets in
Sun Ray...looks real spiffy...wish we could replace our public labs with them, instead of having, like, 40 computers per lab at @$1000 each plus maintainence costs and funky software distribution mechanisms.
It's 10 PM. Do you know if you're un-American?
In the commercial world the value, if any, of thin client is reduced deskside support, reduced helpdesk calls, reduced client rebuilds, reduced complexity. Since the real TCO is about 70% people costs and 15% software and 15% hardware the value of any thin client is directly related to the amount of people-time you save by not having to fix, manintain and manage your clients the same old expensive way. So for example you could use a diskless client that gets its boot code from the network and then whatever applications it needs. Or, you could burn the boot code and basic functions into nonvolatile storage and load the applications into the device on demand. Or you could go the Citrix way, boot the device from wherever and run the applications from a server. The client device could be essentially anything - even a full blown desktop that is in some way locked-down from being altered in any way except from central admin. The real value in any circumstance is the freedom to trash the client code, if any, rebuild it on the fly and/or snatch up the desktop device, throw it in the trash and replace it with another cheap device quickly and easily. Since PC's cost so little there is no value in worrying about the cost of the device vs. a thin client. Instead focus on the amount of time keeping the client device config'd and running correctly. The downside to all of this is that if your central admin encounters a problem or a piece of client code that doesn't work then many clients are effected at the same time. On the other hand fixing it once is x times the number of clients cheaper to recover from.
I use the Windows 2000 terminal server from at home at 26,000 bps and it screams. It has a faster response time than my host 233MHz NT 4.0 machine's own response time for UI (no big feat). The Win2K terminal server is based on Citrix.
It this comes to Linux, this would be an excelent replacement for X11 over a modem which is slower than $#1+. It will be worth the ca$h.
There seems to be agreement in the fact that the bandwidth and connectivity is increasing and soon may be as ubiquitous as the dialtone. That's a good thing.
A great deal of work is being done on web browsers to support more and more functionality. JavaScript, for examples, is an attempt to get programming in the browsers. Servlets are fine, but still constrained by the HTML widget set. Applets are problematic as Java support in browsers is problematic. And plugins are just plain problems.
Some folks have mentioned VNC as an alternative approach. Others mentioned X. How about a slightly different view.
Java seems to perform very well (at least where I work) on server side applications. So long as there is no GUI, the systems run great. This makes sense, as Java gives the developers a consistent processor/OS to code to. For non GUI apps, this is possible because most all OS have the same basic functionality (i.e. memory management, file system access, networking, process control, etc). The real differentiator is the user interfaces. All work differently (except Telnet ;-) ).
So, why not create a viewer that is consistent and applications are written to it? I know X is sorta there, but there are some problems with client side requirements and no session saving.
What about building a browser that is nothing more than a canvas for paint commands and an event gatherer. Then, build graphics libraries for your favorite development tools (AWT.so, libx.so, Win32.DLL, etc) that use this viewer as the graphics context. Now we could run the applications anywhere.
How does this affect browsers? Well, instead of adding more and more functionality and rendering capability into the browser (XML+XSL, JavaScript, VBScript, etc), the web servers become the rendering engines. Put all the rendering at the server and just send the paint commands to the viewer.
This way users don't need to wait Until the browsers support what I need, or make different versions for different browsers. If new functionality is added to the server, then all users now see it.
I'm thinking something like the GGI project along with VNC (which there is a mapping to by the way), might get this type of project started.
I note that ATT labs which owns VNC is using it in conjunction with CORBA. They don't want to release that as they don't want to support it. But imagine the possibilities.
Sorry for the length of this post. Just thinking out loud.
What an incredibly useless (not to mention offtopic) comment.
Java is far from being a Lisp interpreter. Its syntax is more like C than C++. And it has a much more specific task optimisation than Perl. What task is Perl optimised for? Pretty much the same task as C is optimised for, i.e., anything at all.
Conclusion?
Faster?
The Citrix ICA protocol is remarkable... it compresses the screen changes so well that you can run applications very smoothly over a mere 56K line. VNC, while very flexible, is much more bandwidth-intensive, and feels pretty sluggish even over a T1. They say right on their web site that it was designed for high-bandwidth LANs.
(VNC is highly portable and free, though. We have deployed it to every server and workstation to allow remote administration and help desk support.)
The key advantage of the telnet based solution was that there was only one copy of the executable on the host - even though it was being run from hundreds of desktops. This makes upgrades/admin a lot easier. So the problem was how to get this kind of model, but deliver the windowed environment.
We looked at X, but running an X server on the desktops (PCs with Windows) was too expensive per seat
We looked at HTML/http. No good for data base applications (field validation, field completion, lookups etc aren't easy with a page at time model, session management etc).
We looked at Java. Too slow, immature and not really that "thin".
Then we came across DSI. This stands for Development Solution for the Internet. It is built on XVT's GUI portability kit. You create your application as normal. At run time, instead of calling the local graphical API, the GUI calls are routed across the network, then displayed using a "browser". So you get a Windowed application with a native look running on the client desktop - but the real application is running on the server. You only need a single "browser" (a bit like a telnet application) on the PC.
It's taken quite a while to iron out performance issues etc, but we are now deploying some nice graphical applications which are as easy to manage as the old telnet style applications.
First of all, thin clients have been around for a long time. Back in the old days, we called them X-Terminals. (And we were greatful!)
Currently, there are a couple of flavors of thin clients:
X-terminals:
These have enough brains to run X locally and that is about it. Everything gets run over the wire. Some have web browsers and a few other apps available locally to reduce overhead. Most older X-terminals will do only 256 colors, but newer ones can do up to 24bit and sometimes even 32bit color.
Windows-based terminals:
These talk two basic protocols: ICA and/or RDP. ICA is a protocol from Citrix. RDP is a protocol from Microsoft. (Adapted from an earlier protocol used by Intel, if I remember correctly.) ICA is much faster than RDP, but they are both slower than X at the same color depth. Both of these protocols do a maximum of 256 colors. They are used for multi-user NT and WinFrame/WinCenter multi-user NT. ICA is available for Linux running under X in 16 or 256 color mode from Citrix, but only for connecting to a multi-user NT server. RDP is not available for Linux at all. (At least not officially.)
Some terminals will run all of the above protocols, plus a few more mainframe specific ones. The Java boxes are just an OS variation. They still talk the standard protocols, but they are able to run more apps locally.
There are a couple of advantages to running thin client boxes.
1) They are very small. Since they have no hard drive (and most have no fan), they are small as a standard O'Reilly book. They don't eat up most of the space above and/or below your desk.
2) They allow a centralized location for all of your applications. Your IS staff can upgrade their whole office at once and not have to go from desktop to desktop.
At one time there were a number of applications to blur the line between client and server and between Windows to Unix. Due to Microsoft (and a certain non-MS CEO proclaiming X is Dead), the market for such apps has fallen on hard times.
Don't think that a thin client is "just a cheap PC". There is a different principle behind the design. A cheap PC can be designed to work like a thin client, but it takes a little work and is not always a good emulation. - Someone who works for a thin client company
Actually I found a little bug in Netscapes POP Mail Client that causes my HP10.20/Motif to hang indefinitly requiring a reboot (not a plesent proposition around here).
*The world looks a whole lot better through Rose Colored Glasses*
Regardless of my opinion, I would be curious is the results of suggestions from other developers to this question. tia, Chris
I think the best way is to make use of as much HTML as you can. While it may not be the most efficent, it is the most standardized of the 3. We have implemented our own language called PSX, a plug-in dll for most NT based web servers, and expect a linux port soon. We use it to generate HTML reports.
HTML is competent for data entry... but might benefit for more tags to facilitate that. There are a slew of rules for displaying output, so much so that compliant browsers can serve as capable reporting tools, why not add standards to make data entry more flexible?
I'm not a big fan of Java, and am definatly no expert, but it seems building even simple Java applications isn't easy. GUI elements seem testy and sluggish, ie slide bars not refreshing, scroll bars acting jumpy. And mostly, I see applets out there, not full java applications. From an end-user-ish point of view, it seems silly that we need to load something else once we've loaded our browser up.
Check out PSX at www.primedata.org/psx.htm.. our language does a lot, but it doesn't do everything. We use it mostly for reporting systems for the financial sector. For reporting, it's great (we do some trade entry with it), for other things, it's no so great. Lots of development time goes into making your web browsers, might as well make use of them.
I'd like to 3rd this suggestion. In addition, Scriptics will soon be reviving development of the tcl plugin and be adding additional widgets to the Tk toolkit for ever BETTER looking GUIs. Decent speed, great GUIs, ODBC, easy to learn/develop in AND it's open-source! Not to mention it has a solid company, founded by the creator of Tcl/Tk, behind it. Check it out: http://www.scriptics.com
We ised tcl/tk for a similiar project. Worked GREAT. There is a Perl/TK as well, but I've never used the TK mod for Perl.
We implimented this change because Java/html solution was to cumbersum.
I strongly believe in HTML front ends because of their ease of deploying (don't have to deal with JVM issues or specialized SW on the client). You can develop some really rich GUIs on HTML if you throw in some Javascript. But the ultimate is XML/XSL: with a capable browser (IE5 or future Netscape 5), the client takes over a lot of the processing associated with presentation, and you get very rich UIs. Also, since the style sheets are cached at the client, it's friendly on bandwidth (only the XML part gets sent, not the XSL). -TheShoe (forgot pw)
$1000 seems like alot...
:)
you can build a nice XTerminal with a thrown
away PC. I have seen it work well with something
as "Slow" as a SUN IPC and as "Fast" as a medium
way Pentium (not II not III more like a Pentium
120)
I wrote up some Docs (which are sorely in need
of update if I ever find a spare PC and some time
to work on it) at
http://people.delphi.com/sjc/linux/poor.html
hmmm perhaps soon
-Steve
"I opened my eyes, and everything went dark again"
The point was you said that when IE crashes, it takes down windows.
That was incorrect - and I guess you took that from the idea that web integration means IE is in the kernel or something...anyway....certainly any app not written properly can take down windows, since win9x doesn't protect some vital areas of memory. I don't have this problem in NT (well W2K).
IE overall - even on non NT systems - has given me less trouble than netscape.
This is a suite that runs with the thin client/server model and has its own powerful object-oriented development language in it besides being a full office suite...
Applix Anyware Office
For what it's worth I think the new chips for the PlayStation and Nintendo are going to have a serious impact. Couple that with the requirement for HDTV to have LOTS of fast RAM and you've got the makings of a smart, inexpensive "terminal".
Then, the next step is to simply run whatever browser technology is current at the time. That gives the end user the option of using a Citrix type of remote desktop in the browser or simply using browser based apps. Of course then there is the unlimited addition of cartridges for games or business. Imagine a cartridge with hardware encription and a specific business application.
Given the speed at which things change - whatever you code, better make it portable!
RIP was replaced by HTML/javascript/whatever. RIP BBSes were extremely primitive compared to todays web. That stuff was trash - pure trash.
http://www.viewtouch.com
Front = HTML + JavaServerPages + XML + IE/mozilla (if it ever gets past beta)
We're putting this to use in an international application & so far things are smooth! One drawback is the sorry state of browsers re compliance to standards. Unfortunately, Netscrape just can't cut it for serious GUI development right now so the focus is on IE as the target interface. One advantage of thin client is a malleable look & feel to the interface. If you know yer way around CSS, with a couple stokes of the keyboard you can have a completely different look, or even a customizable interface.
The *best* thin client solution is OS/2 Warp 4 with its best-of-breed GUI, as a thin-client running your choice of Java, DOS, native OS/2, and Win16 apps. Visit http://www.os2hq.com/ for more "Warped Perspectives".
Javascript is a hackish, crappy language... It is no where near as elegant or as powerful as java... anyone who thinks otherwise has never used java and needs a clue...
"Conclusion? Write in C. Or assembler, if you can. Or anything but BASIC."
Why not basic, it would suit you just fine judging from the rest of your post: ugly syntax, close to all those nice GPFs and blue screens and other interesting stuff you encounter when you descent to that level.
Assembler is nice if you are exclusively interested in performance. C becomes an option if you care about other things too but performance is still very important. Then it gets interesting because there's a whole bunch of languages each with a different goal. Perl: ugly syntax, good for implementing something fast, performance is also nice but could be better. Java: clean syntax, also good for implementing something fast, performance could be better but can be adequate in some domains given good programmer skill.
Conclusion c is for hardcore programmers who like to stay close to the hardware, perl is for people lacking programming skill who want to get the job done anyway and don't care about maintenance, Java is for people ranging from novice to hardcore programmers who like a powerfull language but also care about maintenance, scalability and platform independence.
Conclusion, you should reconsider your conclusion. I don't want to say perl is bad. I must admit I have looked at to see if I could script JavaBeans with it. In my opinion scriptlanguages can be very good for glueing together components in a system. You should check out www.scriptics.com if you are interested in this sort of stuff. One of the persons there, John Ousterhout wrote some interesting stuff about the use of TCL/TK in combination with Java.
Jilles
I've been trying to figure out just what is meant by a thin client. Is the case thin? Just what do people really mean?
Processing power is so _cheap_ that there isn't really any point in skimping on that. The same is true of all components of a modern pc -- if you can get a servicable PC for $200-300, then what's the value of a handicapped terminal?
The closest thing we have to a successful thin client is the Apple iMac. It's designed explicitly for networking, lacking any external storage options in its basic configuration. But it can do video editing, so it isn't really "thin".
Then it hit me -- the thin client isn't the computer, it's the person using the computer. The main attractivness of having networked applications is not to do the computing over the network, but to do the installation/configuration/etc. over the network. It's to create a firewall between difficult techie issues and uninterested users.
So the ideal thin client architecture is one in which all administration can be done remotely. One in which all the user has to do to install an ap is open a network folder and browse.
btw, if one can code Java, then you can figure out the awt. Also, is HTML/XML really thin? Browsers are pretty sophisticated apps, just ask any would be Mozilla developer
I was once involved with rolling out an application for worldwide deployment by a multinational company. Through that experience I learned that HTML with perhaps a Java front-end for doing field validation and such makes the most sense.
This is not a bandwidth issue, but an issue with the "speed of light" and the long latency times to get packets around the world. (The situation I was involved with required servers in north america, while some of the offices were as far away as Hong Kong.)
As much as I love Xwindows, this was totally unsuitable because much of the underlying chit-chat for the X protocol is "synchronous", meaning that the client will send requests to the X display server and wait (and wait) for it to respond before sending the next request. There can be hundreds of transactions like this just to bring up a simple window, meaning that it can take several minutes. Bandwidth was not the issue.
Since the application was written using X, we also tried dxpc, lbx and other compression techniques. It improved, but not by much.
The thing is, with that kind of latency, even telnet sessions are not very nice!
We also tried various techniques of client/server, distributed database, VNC's, caching etc.
What really works is some kind of an HTML front-end, which let's face it, is very much like the block mode 3270 terminals of yore with a bit of window dressing. This gives the users the perception of a responsive application most of the time, unlike the other solutions we tried.
I'm not fond of Java as a general purpose language, and I certainly don't think there is any benefit to using it on the server side where performance is usually more of an issue, but on the client side to facilitate the front end of an application it does make sense.
buddy, you are WAY off base here. do you know anything about java? have you ever tried to do anything complex with javascript? don't take this the wrong way, but you are seriously deluded if you actually mean that stuff. anyone in the know will agree that javascript is absolutely horrid. thanks for the laughs anyhow, and best of luck with your project, i'm sure you're gonna need it.
*sigh* I wrote my post in English. Be glad I don't reply in line numbers.
:). I like to use shell for this too. It's slow, but the whole point of a glue language is that you shouldn't be using it enough for it to be slow. All the real work should be done by something fast, like... C.
;)
I don't like BASIC because it is generally slow and interpreted and weak. (i.e. not powerful, you shouldn't have to code around the language to do basic tasks) You should have gathered this from the content of my post.
I'm interested in performance. C is good. Assembler is better for optimizing code, it's great if you can write that code for a couple of platforms, and include it in as needed, with substitute C code for other (unsupported as yet) platforms. MAME does this for some of its CPU cores.
Perl and Java speed implementation and are therefore good for prototypes and hacks. However, if you know C, it's great for hacks, and actual implementations. And it's already really portable too. Some Java VM's might get faster at least, they're still maturing. Perl will probably get rewritten into C++ for maintainability, so we'll see if it gets slower or not.
I'm not really saying that Perl or Java is outright bad, but for performance and real products that might need to run on, say, 486's with 8MB of RAM, they are obviously not the right choices IMO... (on a platform like that, I'd want the most speed possible!) And this is the platform that OSes like Linux like to claim to target. At least the GNU utils are coded well in C, but I remember when RedHat used Python for some of their control-panel tools, and it sucked...
Glue languages are fine, that's what TCL was supposed to be for, and what a lot of people use Perl for (or some freaks who use Scheme
VNC does have a Java client. That's okay. Why? Because VNC is slow too, usually because of network bandwidth. Java is fine, provided you make sure that it's not the bottleneck. Use it on the WWW, when you're waiting for a slow site or a modem, say, and it doesn't look that slow anymore.
And I think I had a 'holy war disclaimer' at the beginning, but these are of course my opinions.
---
pb Reply rather than vaguely moderate me.
pb Reply or e-mail; don't vaguely moderate.
One group of folks needs to write some XML/XSL/Java widgets once, then java servlet apps can use something like Apache's Cocoon to spit out DHTML/HTML/WML/VML/FooML: the best depth and markup for the particular client browser. The future is full of different kinds of clients, but you should only have to define new mappings, and you should do that using a high-level toolbox of XML structures and XSL translations. Anyone interested in building such an (Open Source) system? Anyone know of something similar already existing? If so, please mail me: jeremNywerneOr@ySahPooA.coMm
Delphi browser clients were Windows only (ActiveX) in version 3 and 4, but now in version 5 clients can be DHTML/XML. There is still a dependency on DHTML and XML (this is a good thing!) but it's not tied to Windows.
or an old 386 + ethernet card + packetdriver + mskermit 3.14 configured as a vt320.
A mouse and a GUI makes data entry applications SLOWER.
I'mn pretty sure that IBM's workspace on demand would like up to your requirements. It has excellent support for Java (and what doesn't have good support for html), plus it is an established architecture. It's based on OS/2 (don't hold that against it - for specifica tasks OS/2 is excellent). It's a really smart system, and now that Netscape finally have a latest tgeneration and actually stable browser running on the platform, it is quite usable.
Believe with me, my saplings.
What may be helpful, on the other hand, is to make sure there are ways of splitting applications into modular pieces so that you can have pieces on hosts here and there, and thereby keep the graphical pieces fairly thin.
To that end, I would commend the consideration of message-oriented middleware systems; there are expensive ones like Tuxedo or MQSeries, and "libre" ones like Isect.
Keep in mind that you can't keep the client thin unless you have already split the application cleanly into pieces that allow the client to stay thin...
If you're not part of the solution, you're part of the precipitate.
University of Georgia Department of English. Old, throwaway 486s as X terminals, with a central application server. (Disclaimer: not my project)
This message has been scanned for memes and dangerous content by MindScanner, and is believed to be unclean.
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!
I think the greatest thing since slice bread was and is remote X sessions. :) Nice nice happy and thin clients that because of the magic powers of X11 can run remotely very easily. It seems people these days forget the happiness one can achive with an xterm and a beefy server :) Sure Quake is not an application for x-terms but one can do data entry and solitaire on these machines. Plus you don't have to worry about the users killing the x-terms because they really have nothing too kill. :) But then again that's my 3.234128734192222222222222222224341341 cents (Canadian)
If you really want to do some thin client apps, why bother with the client at all? Forget about the client completely, spend the money on a fat ass server to do ALL the processing. There is no reason for the client to do anything at all but to display info and accept input. Amazon is a perfect example. Hell, you can order books with a Palm Pilot now. The clients don't get much more thin than that.
You don't need Java, you don't need cgi, all you need to do is process your info and publish it in html. Get the job done with bandwidth and processor power. Damn! Yankees just won again...
At the opposite end of the spectrum, the X protocol provides infinite control, but requires that you layer lots of stuff on top of it in order to do anything.
It may be worth looking at the PalmPilot; it represents, above all else, a useful set of compromises.
What is probably needed is some such useful set of compromises, a reasonably powerful widget set like one of
- Tk
- Gtk
- Qt
that has:Your idea of transmitting XML interpretable by a GLADE "server" on the client is certainly not outrageous; I would suggest the thought that it might be worthwile to have a protocol that passes across pre-parsed XML so as to cut down on the amount of network traffic.
The thing that libGlade does not (yet?) seem to admit is that of extensibility. In order to support that it would probably be necessary to have some form of interpreter on the client that can run (bytecompiled?) code to either provide additional widgets or to provide some further local processing.
If you're not part of the solution, you're part of the precipitate.
I am not so sure about Notes. I installed it on my machine at home in order to communicate with the office. Just to get email, and access project group projects. This took 100Mb of client install. Like you said, it's painfully slow. I can't see Open Source(tm) saving this program.
Upon seeing the box was too small, Schrodinger's Elephant breathed a sigh of relief.
It may be too constraining to say that computation should be either remote (a la X-Windows) or local (Microsoft Windows). I agree that word processing is a prime candidate for local processing, but I'd say that heavy-duty numerical applications may want to run on a remote server.
Furthermore, if we're assuming some kind of intranet here, then the processing power of all the servers and thin clients should be viewed as a common resource. So I may call up an application on a server, and if my own terminal is working too hard already, then the application runs on a third machine with the results coming back to my screen.
To my untrained mind, this sounds like a job for Underdog^H^H^H^H^H^H^H^H CORBA. A CORBA-based application manager could provide load balancing across machines in the intranet.
If the CORBA application manager remains in user-space, then it should probably take the form of a desktop environment (such as GNOME).
However, if the CORBA app manager could be swallowed as a module into the kernel, then it could be used to create dynamically "mountable" processors, in a manner similar to NFS. Of course, in order to acknowledge network latencies, the kernel scheduler should provide some method of processor affinity, so that remotely running processes stay on remote processors, instead of thrashing back and forth throughout the network.
If I just had a little time...
Your complaint against Java is that "programmers shouldn't need to write gui code". Have you checked out any of the non-programmer oriented java beans builders? Such as Lotus beanmachine or Jamba? You can build sophisticated guis which talk to databases with no code. I know you've probably heard this before, but this time I think they've done it. Java beans really are cool.
As for whether it's "thin enough". Well I think it's as thin as you're going to get whilst still getting all the features you may need. As you say, HTML is thinner, but it's also lame.
Saw something really wierd yesterday... secretary was using Word97 on an NTSP4 machine. It rebooted. Guess you can't really say it "crashed" since there was no blue screen... just instant reboot. One minute life is about as good as it can be while using word... the next you are looking at the memory check and BIOS finding devices. I _think_ he may just mean that Java in browsers have a higher rate of bringing down the whole machine, not that it happens ALL the time... but it certainly DOES happen.
We have ColdFusion 4.0 running on Sun Solaris w/ a large Oracle database server. This proves more than adequate when simply doing data processing and dosn't have much overhead. People access the apps over our intranet through their browsers and do what they have always done and because we stick to basics, it runs across many platforms without much worry.
I'm not saying this is the end-all be-all, but it has been very effective in our environment and shouldn't be dicounted just because it dosn't provide all of the bells and whistles. Of course, it depends on what you're doing.
If you need a real-time interface then you are SOL right now. Sorry, Java just hasn't lived up to it's promises; such an unfortunate thing.
-- kwashiorkor --
Leaps in Logic
should not be confused with
Jumping to Conclusions.
I've used a product called GoGlobal by Graphon which seems to work pretty well. It is basically a thin X client for PC's. In my experience, applications run fairly well even over a slowish modem link, and over a LAN, they run like you were sitting at the server machine. They also have a Java version, which I have not tried. This would seem like a good solution. Develop the application on a unix machine, let people run it from any Java capabale client.
I am a dynamic figure, often seen scaling walls and crushing ice.
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.
I've finally had it: until slashdot gets article moderation, I am not coming back.
There's one _very_ important point here, that I've synthesized my opinion on from a mish-mash of Alan Cooper (many of whose opinions I _violently_ disagree with, BTW), Jakob Neilsen, Phil Greenspun, and half a dozen others:
There are two major types of applications:
1) Ones I _sleep_ with,
2) ones I date occasionally.
The latter can easily be implemented as fancy browser based graphical UI's which are easy to train... but in the case of the former, ease of training is _much_ less important than ease of _use_.
I've seen 3 or 4 mainframe applications where the re-write made the app look like "Windows on a TTY"... and spread 1 or 2 screens of entry out over 14 screens.
They are _unanimously_ panned by the people who have to do heads-down data entry on them all day long. Allied Van Lines did it; the Florida DMV has just done it... and you shouldn't.
Non-productivity applications that a user lives with all day long -- that is to say, database front end-y stuff, not word processors and calendars -- should be 80x25 in a text window.
Trust Me on this.
Cheers,
I'll second that. I was going to post the same thing, but I read through all the comments first to see if anyone said it.
Tcl has the advantage over Perl of being a bit easier to read after it's written, and it integrates with the Tk library much more easily. You can write your applications in Tcl and use them through the web browser via the plug-in. All you'll need on the client side is a browser. The plug-in supports the sandbox concept, meaning that the Tcl scripts that you write will be safe for the users to run through their browsers. The gui's that you write will be good looking, and easier to develop than the equivalent Java gui. For more information on the plug-in and the Tcl language in general, go to www.scriptics.com.
If tits were wings it'd be flying around.
A major point:
"Thin client" is a marketing term. It doesn't have anything to do with the 'fatness' of the computer itself. Check out this link to Sun.
The key is in the blurb:
"Are you looking for centralized administration and a rich user experience? Look no further. The "plug-and-work" enterprise appliance requires no client administration or upgrades while at the same time putting the power of the server on your desktop."
Thin clients aren't about dumb terminals; they're about terminals which remove the need for users to do any kind of administration. Notice that this has nothing to do with X windows, XML, Java. Nor does it have anything to do with CPU, etc. It doesn't matter what the box is running, as long as all the user has to do plug it into a jack and turn it on.
The OS gets tossed because it is confusing, not b/c it eats too many resources. The CPU, file system, and memory are all trivial costs. It's the service calls that are expensive.
Therefor, it isn't appropriate to discuss thin clients in terms of these non-factors (OS, windowing technology, etc.). You want a thin-client solution, pick X/Java/whatever and build something your users never have to think about.
I am currently running a "thin" network. I have 23 iMac clients with no hard drives booting over the network and recieving all apps from a single Unix Server. I run MacOS on the clients and can update the entire lab in one shot by modifing an image file on the Unix box. This is one of the best most robust solutions available. When MacOS X Client comes out in several months look for all Unix networks making a comeback with MacOS X Client booting from the network and X Sever on the backbone. This is a solution that I have working TODAY!!!!!!! Apple's netboot solution is excellent for enterprise and I would recommend it for any lab or group of machines that need centralized adminsitration and cheap hardware.
"... Sun make money, ubiquitous connectivity is a threat to them."
Ever hear of NFS, moron?
"If everyone can communicate with anyone else, what would we need them for?"
That's how Sun got so successful in the first place--embracing open standards like BSD UNIX, TCP/IP, etc., and then licensing their creations like NFS.
I'd say that's a hardware problem :)
;)
Things like that can happen....background radiation
http://www.zdnet.com/pcweek/stories/columns/0,4351 ,2377721,00.html Enjoy!
Got warning: "Because of the limitations of JDK 1.1..." and then goes on about the lack of security! Nice environment. Crashed in 10 mins.
The so-called "thin-client" provides the UI--the actual interface controls the user sees and touches.
The UI interacts programatically with the actual application, pieces of which might be running on one or more remote hosts.
The application itself may interact programatically with one or more databases which might be hosted on one or more remote servers.
So the actual programming occurs in the application, not in the thin-client. But the thin-client needs to report all events to the application in real-time, allowing the application to repond to those events. This is where HTML alone falls short. The only event it reports is a submit. So you add a bunch of JavaScript to report events back to the application. Hmmm...
What if [HT|X|My|Your]ML actually reported events such as a selection change within a list box, without needing JavaScript, and without having to press an additional submit button? What if different events could be reported to different pieces of the app on different hosts? The code might look something like this:/ listbox1/item-changed.event"/>t window/listbox1/scroll-up.event"/>
<control type="listbox" height="5">
<event name="item-changed" action="http://www.somewhere.org/myapp/thiswindow
<event name="scroll" direction="up" action="http://www.somewhere.else.org/yourapp/tha
<item>List Item 1</item>
<item>List Item 2</item>
<item>List Item 3</item>
</control>
Next, the application needs to be able to refresh specific controls on the thin-client without re-generating entire "pages".
Alright, that's enough pondering of that thought for me. I'm getting out of my league. Somebody who actually knows something can probably tell me the name of what I've just described.
"And then there is the (MS sponsored) murder of the portability promise."
If we are supposed to avoid Java because Microsoft has targeted it for termination, does that mean we should also give up on Linux?
I suspect that HTML and Java will suffice as a thin and sorta thick (respectively) client-side interface for simple projects, such as data entry, inventory control, and other sorts of jobs which would have been done a dozen years ago with a bank of VT-100 terminals. And I suspect that XML will be comming around the corner in a couple of years to fill in the blanks that HTML currently cannot cut.
OTOH, I suspect there will always be software projects where a thin client-side interface just ain't going to cut it. But for MIS departments where all you need is to support your customer support crew with latest technical specs and access to the customer database, HTML on the client side is a fairly good answer overall.
Of course this requires a lot of metal on the server side, as well as a fresh copy of Apache and PHP (which IMHO rocks!), but that's the other side of the wire...
Citrix isn't bad, but you do occasionally run into problems that aren't found on open platforms (like X). We use a model of ICA terminal that has CLIENT-side freezups occasionally that pop up when the user runs Outlook on the server. That really isn't supposed to happen. Ever. Server-side freezes are expected with MS trash, but client-side? Thanks to the closed source nature of ICA, we can't ever troubleshoot it effectively, and our vendor is completely unresponsive. Fortunately, the rest of the company is running on XTerms (NCD has a decent add-on for WTS that lets it do its magic over X), so we only have to deal with it for the remote offices (ICA is much better over the WAN than standard X, and out terminals don't support LBX).
The other problem with WTS is all the hoops you have to jump through to get programs properly configured (I've certainly done more than my share of registry hacking to get it all working--even with standard apps like Office '97). Without proper configuration, wierd stuff happens, like any user being able to change applicaion defaults for the entire system or file sharing violations.
All in all, it makes me want to port our proprietary DB stuff to HTML and run Office apps via Wine on a beefy Linux box. At least proper configuration for multiple simultaneous users would be easier (that's a scary thought).
"Time flies like an arrow; fruit flies like a banana." --Groucho Marx
I used to think this way too, but over time, and with much pain, I learned the hard way that Perl is superior to java or c/c++ when it comes to web/db stuff. Why? Because Perl is the most efficient language for dealing with text, and web based applications are primarily all about text. Java and C/C++, which I used to defend to the death, are much clumsier with text than Perl. It's true! I even prefer the way Perl allows very flexible object oriented programming to the old Java/C++ days. The programmer is given incredible control and expressive power. I must admit, I haven't yet played with Python, though. Now if I need to quickly render a few Mandelbrodt sets, I'll probably do it in C++ (or java, if I'm not in a hurry to see the pictures), but for web stuff give me Perl!
I used to be really turned off by the "ugly" syntax, but now that I'm accustomed to it, I can't stand looking at Java anymore. IMHO, most things can be done much more elegantly in Perl.
Something worthy of note is Jade, it's relatively new, Object Orientated and the latest release offers a variety of clients, including a Smart Thin Client and an Html thin client. Some of the work I've seen done on a database system we were evaluating as well as with my contacts with the developers, The Cardinal Group, here in Christchurch, New Zealand has been very impressive. Check out: http://www.discoverjade.com.
http://www.computerworld.com/home/news.nsf/all/990 8231gad OS/2 Warp Server and Workspace on demand will certainly be a good choice.
It was designed for this. Today X terminals are dirt cheap and machines like UE4500s can support a hell of a lot of them. Even the old Sun 4/600 series does a wonderful job at this for departmental servers (rather X clients in this case). Why invent the wheel when it's already been invented?
Take a look at http://www.wapforum.org for yet another approach to thin client architecture. This is the stuff that is going to get stuffed into pagers, cell phones, PDAs... most of the big players are adopting this emerging standard.
A client that would understand tcl/tk
plus html/xml would pretty much fit
your bill in my opinion.
You can setup a linux box doing just that.
If you throw in the (unfortunatly quasi
defunct) tcl plugin for netscape you
have something pretty much cross platform
and much easier....
I have been setting up some thin clients based on our old (8MB, no hard disk) 486s. I boot off a floppy based on a modified LODS, which in turn is a modified Hal91 distribution. The machines are too small to boot X (thus, I can't use muLinux - it needs at least 16MB to boot X). VNC is ideal for me, I can have one big server with 10 running copies of the application I provide to the clients, which are completely stateless - you just boot the client and it appears exactly where you left it. On a LAN, display speed is perfectly comparable to X, and it can also be deployed (albeit VERY slowly) over a modem.
;) )
;)
I don't buy Java. Simply, it is an ugly language. If I were to start selling and marketing an all-purpose thin client solution (unlike mine, which is very purpose-specific), I would maybe build a Perl interpreter into its hardware... It would be much more appealing than Java to many programmers. (Of course, I'd have to get big bucks to do so
Anyway, my 20 mexican cents worth
Check out Speiros at www.cyrusintersoft.com for a free Java Desktop that offers mobile use and transparent app distribution.
The ideal of Java is great. The implementation on browsers is less than perfect. There is a reason there are so few java enabled pages: java crashes browsers. It's even worse on Microsoft, it takes the whole machine down.
See AT&T Labs UK VNC Pages
Computers, Linux, NetBSD,
From:randall_burns@hotmail.com I don't think either of the first two folks to respond to this article even bothered to read the initial article in this thread. Think about it: Every computer in creation is soon likely to have a web-browser with JavaScript built in(even telephones and palmtops). This means that JavaScript will be available in places where an additional run-time will impose considerable costs. The real "Thin Clients" right now are Palm PC(Windows CE, Palm Pilot etc).--and they are getting increasingly hooked up to networks. This is the kind of architecture that really could drop to the price of telephones and calculators--and a pretty good minimal functionality is "can run web browser". Asking whether is is "hackish" is IMHO the wrong question, the right one is "can JavaScript be fixed".
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.
How 'thin' do you want the application?
I can hardly think of anything thinnier than a telnet. Works nice in everything between Memorex to Cray.
/sarcasm on
Do you really need bells and whistles? Then don't loose your time and use VB/ActiveX. Nothing will make Windows fatter. Won't be portable, will break every couple of minutes, will be incredibly slow, but... who really cares? Looks nice!
/sarcasm off
There are a lot of considerations when deciding what to do for a 'data entry' application. How intensive will the data entry be? Is there a lot of data validations prior to end your transaction? Is it database intensive? Is it calculation intensive? Will it use some/dozens/hundreds/thousands of screens/forms/reports?
Lots of times a poorly designed GUI is worst than a well designed character interface.
Can you wait 'till there's Linux Delphi?
Is portability a big concern?
Can you spend a lot of money in processor power?
Have you considered other proprietary solutions, e application builders like Compuware's Uniface? (quite portable, very good for DB intensive apps, but too much proprietary and very far from thin).
As far as I see, Java isn't a bad solution. It is stable enough, you can distribute workload between client and servers and, as you say, only malicious borg code breaks a well-coded java app.
Python can also work well (structured, robust, fast, easy to learn -and easier if you already know perl)
I feel your question too broad to have a simple answer. Good luck, anyway.
What do you mean by:
As I understand it libGLADE allows you to write the UI in XML, which will be translated to GTK widgets by the library. The signals from the widgets need to be caught by your program.
If this is correct (corrections please), then couldn't a generic signal handler be written to pass the signals back to the server computer (not the one the GTK/XML app is on, the REAL server)
Of course, this wouldn't allow upgrading of the GTK library, if that is waht you mean. (?)
Right now I'm doing that kind of thing with Java on the backend and HTML (& some Javascript) on the frontend. No doubt about it, HTML (even with Javascript and layers and all the extra stuff) is just not good enough to produce a decent GUI. You can get close, but at the expense of a lot of tinkering...
We are starting to move to feeding out XML, and for clients that still need HTML (which will probably be most for a while) just parse the XML into HTML on the server.
If it was all internal apps over a good network, the Jvaa Plugin is pretty useful as well - using that you get the same VM on both IE and Netscape, and get to use Java 2 right now. I used that for a project and it worked out really well, though I'd have to agree that solution is a bit too large to really be called a thin client - it was more a distributed app.
Flash 4 also supports forms now, I suppsoe you could use that though it seems somehow wrong... in a recent demo they gave at our workplace they showed a -whole desktop- (calculator app, mini browser windows, etc) built all in Flash. Yipe!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I guess what I would be looking for is something that runs most of it's core logic on the server side and only has presentation on the client side. I would also be looking for something that would automatically upgrade itself when new changes are released. Those new Sun Rays offer a nice model.
IE crashing does not take down the whole machine.
If you have IE set to start in a new process, it won't take down anything. If you're spawning IE in the same process as explorer, it'll take down your shell, but the shell will restart.
It's like saying "Netscape locks up linux and shuts down the WHOLE MACHINE"
I use a number of different 'thin client' type protocols on the networks I administer - X is a good protocol, but not very 'thin'. It doesn't work very well over long distances. On our Lan we have a number of X-terms that connect to DGUX servers, all of which can open a windows NT session on a box running Windows NT Terminal Server with Citrix Metaframe(sure, it's Windows, but get over it - users want Windows/Office). Additionally, we have PCs, Macs, and NCD ThinStar WinCE terminals. All can run the same applications, in many cases much faster than they could on their own machine. Plus, it really saves you money in the long run, because most users don't really use all the power a regular PC can offer, except in brief bursts. Maybe 10K for a huge server, and then any piece of crap can connect to it - instead of spending 1K for every person in the office.
Although WTS is a bitch to configure, once it's there, it works really nicely. Citrix ICA is an excellent protocol - it has clients for windows, mac, linux, solaris, java, etc, and can even be used over a modem, with encryption, with acceptable speed. People with the terminals as clients are easy to take care of. They won't screw up their machines, and if something goes wrong with it, we just pop in a new one and they're back online. Of course, Windows Terminal Server is pretty obscure at the moment, Windows 2000 will support terminal serving capabilities as well.
If you want multiplatform thin client capability, the names you need to know are NCD, Citrix, and Microsoft. VNC is an open-source alternative that works fairly well(although it is far slower than citrix), and supports almost every known platform. Although it has no built-in encryption, it can be tunneled through ssh relatively simply. It has fewer requirements than X, and shows good promise for the future. By the way, they needs more good developers - go to the site.
-lx