Thin-Client Applicaton Architectures? 136
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?"
Thin clients (Score:2)
JavaScript Wins (Score:2)
As a first step, I have a grammar-sensitive JavaScript compressor which I'm releasing into open source. [come.to]
Java can do the job. (Score:2)
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.
Re:Citrix (Score:2)
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.
Whatever Happened to RIP? (Score:1)
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.
Re:local vs. distributed computation (Score:1)
Fortunately, we don't have to depend on CORBA for what you're talking about. Why not look into MOSIX [mosix.com] to see how this is going to be done? (btw, this funded by VALinux now...)
Re:Use HTML for the forseeable future (Score:1)
GUIs are the bane of my existence!
HTML/Java is all you need?" (Score:2)
At the risk of over simplifying an answer . . .
Yes
Pick-yer-script, not your nose! (Score:1)
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?
There's a good chance (Score:3)
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
"thin" client?? (Score:1)
Check out Apache JetSpeed (Score:3)
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
something smarter than X, sort of like meta-X (Score:1)
NFS??? (Score:1)
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?
Thoughts.. (Score:4)
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*
Wait until something better comes up (Score:1)
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.
Re:VNC anyone? (Score:2)
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?
Nice Solution Exists now (Score:1)
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 [apache.org]
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
Mindbright and VNC (Score:5)
Where the hell did Mindbright come from?
Mindbright [mindbright.se], 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
Re:It will take an extreme Open Source(tm) diet! (Score:1)
Re:VNC anyone? (Score:1)
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.
Different approach (Score:2)
HTTP thin clients?!? (Score:1)
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.
Thin Client Real World Example (Score:1)
Re:Citrix (Score:1)
However, for me, telnet is the ultimate thin client. It allows me to run ANY text mode program.
HTML Forms are well understood (Score:2)
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.
Python (Score:1)
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 [python.org]!
Tektronix / NCD (Score:1)
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.com]
NCD Home Page [ncd.com]
Re:HTML/Java is all you need?" (Score:1)
HTML is used as a GUI toolkit (Score:1)
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.
Re:VNC anyone? (Score:1)
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
Thin Clients ? (Score:1)
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
Some thin client possibilities (Score:2)
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.
And the point of thin client is....? (Score:1)
Re:Citrix (Score:1)
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.
Slightly different view of things (Score:1)
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 [att.com] 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 [ggi-project.org] 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.
Re: Citrix (Score:2)
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.)
Developing thing client solutions "DSI" (Score:1)
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 [xvt.com]. 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.
Re: stop being an idiot (Score:1)
*The world looks a whole lot better through Rose Colored Glasses*
Thin applications (Score:1)
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.
Cheap PCs (Score:1)
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
Re: stop living in a dream world (Score:1)
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.
New hardware choices make new thin choices (Score:1)
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!
Re:Thin clients (Score:1)
Thin clients fall into the niche where one needs a device to get work done with a minimal of fuss and tweaking. Today's PC, whether it is running Linux or Windoze or whatever, requires a lot of work to setup and keep running. Thin clients answer the bill by being as simple as possible while allowing meaningful work to be done.
you can do it... (Score:1)
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.
Re:VNC anyone? (Score:2)
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.
Just what are the "thin clients" (Score:1)
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
Re:Nice Solution Exists now (Score:1)
1. Platform independance - these are standard APIs and will run with any Web Application Server, which will plug into any WebServer
2. Coding is in Java which is currently cool - I won't bore you with the rest of the arguments for Java
3. Architecturally it makes a lot of sense in that it splits tasks between those best suited for it - Servlets can be coded by Java Hackers, JSP can be coded by HTML guys as it is essentially a simple superset
4. All the work is done server side, so your browser only sees HTML, meaning it doesn't have to support all the latest "standards"
5. Servlets/JSP lead naturally into Enterprise Java Bean technology which is where you get all of your mission critical, scalable fault tolerant attributes from.
I believe that this is the best way forward for thin client, and to put my money where my mouth is so to speak, I am writing a killer web app in my spare time based in this technology.
If you want to try this stuff, as Chris says, you can download Apache JServ for servlets, and there is a GNU implementation of JSP - also you can download IBM's WebSphere which is cooly available for Linux. (www.software.ibm.com)
Thats it for now
Latency times for WAN aps (Score:1)
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.
Re:VNC anyone? (Score:2)
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.
XML/XSL/Java Wiget Tooklit (Score:1)
Re:There's a good chance (Score:1)
You don't need to design a new lightweight terminal system: just re-discover X. I can't believe that you left it out of your list of options. Dedicated X terminals can be built on systems that would be considered puny by today's PC standards. During the early nineties, the group I worked with had a lab of 20 or so X terminals, NCDs and Labtams. The Labtams were the best, with snappier GUI response than the MIPS and Sun workstations that were also on the net. These machines had a 16MHz i960 and 8M of RAM. No special graphics hardware, but hand-tuned blit code on the i960.
What is it that you feel X _doesn't_ give you that another "thin terminal" protocol might?
I'm no expert on the issue but... (Score:1)
Back End: MOM (Score:2)
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. [netcom.com]
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...
An interesting Linux thin-client project (Score:3)
Use HTML for the forseeable future (Score:3)
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!
Thin who :) (Score:1)
Why bother with client architecture at all? (Score:2)
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...
Remotable Widgets Probably the Critical Notion (Score:2)
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.
It will take an extreme Open Source(tm) diet! (Score:1)
Why you should use Java (Score:2)
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.
HTML + *script + ( PHP or CF or ASP or Perl) (Score:1)
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.
GoGlobal (Score:1)
You want a dumb terminal? (Score:3)
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.
Architecture (Score:1)
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,
Re:Tcl/Tk ? (Score:2)
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.
Re:An interesting Linux thin-client project (Score:1)
Thin Clients get confusing... (Score:1)
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. [sun.com]
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.
MacOS X Server and thin clients (Score:1)
Re: stop living in a dream world (Score:1)
Things like that can happen....background radiation
Java by mzauzig (Score:1)
If we are supposed to avoid Java because Microsoft has targeted it for termination, does that mean we should also give up on Linux?
Don't know if there is one answer, but... (Score:1)
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...
Re:Citrix (Score:1)
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).
Re:NFS??? (Score:1)
Re:VNC anyone? (Score:1)
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.
Re:local vs. distributed computation (Score:1)
-Chris
Jade? (Score:1)
Check out WAP (Wireless Application Protocol) (Score:2)
Tcl/Tk ? (Score:1)
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....
VNC anyone? (Score:2)
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
Re:local vs. distributed computation (Score:1)
Re:Use HTML for the forseeable future (Score:1)
So you want an easy way to store state on the client, but don't want cookies? This is actually planned for Netscape 6.0 -- it's called Oreos. Microsoft has also been whispering about "Project TollHouse".
Seriously, you can maintain state over HTTP without cookies or URL goofyness, but it involves some pretty complicated javascript, which probably wouldn't be cross-browser compatible.
--
Re:Cheap PCs (Score:2)
Re:Slightly different view of things (Score:1)
How about VNC (Score:1)
See AT&T Labs UK VNC Pages [att.com]
Re:Why bother with client architecture at all? (Score:1)
Citrix (Score:3)
How thin? (Score:1)
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.
Yeah! (and Hu?) (Score:1)
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. (?)
XML and/or Java or - Flash? (Score:1)
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!
What is thin client? (Score:1)
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.
Re: stop being an idiot (Score:1)
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"
Java/HTML? Bleah. Try X, WTS, VNC (Score:2)
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 [att.com] 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 [att.com].
-lx