Thin-client terminals revisited

Different people have different ideas as to what constitutes a "thin-client", which creates some unnecessary confusion. Frankly "thin-clients" used to be called "terminals", but in the earlier days these were character based and the only confusion was between ASCII and EBCDIC codes, asynch and synch communications and clusters. But then came the PC and Web browsers!

Long before the PC, engineering workstations were designed to be networked with a file and print server. The PC adopted the same concept at a lower cost and in very high volumes. The engineering workstations progressed to support code in a workstation which could access a shared database and the thick-client architecture was born. At the same time however Sun introduced the now standard remote procedure call protocols, which enabled a client procedure in the workstation to access shared procedures on the server, the basic "thin-client" concept.
Unfortunately the PC suffered from single-tasking software such as MS DOS, Windows 3 and Netware, which made thin client architectures very difficult, so progress stopped dead for many years. The problem then to be faced when multi-tasking PC software appeared was the legacy of thick-client applications. This problem exists today, even though the technology is now well suited to thin-client applications.
Because of the legacy problem an alternative type of thin-client was introduced by Citrix, which was similar to the old terminals, except that it supports graphics. In particular it supports Windows graphics. A server runs multiple copies of Windows in virtual machines. The GUI display for each virtual machine is mapped across a network to a "Windows terminal". This is not a true thin-client architecture since it is multiple single-user rather than the essential multi-user, but it has a good role to play in providing continuity with legacy Windows applications.
The common way to implement a Windows terminal is to emulate one using specific client software on a standard PC, particularly since there are so many already installed. An up-to-date Windows system is not necessary, an old Widows 95 machine will do. However a number of hardware suppliers, notably Wyse, make dedicated Windows terminals, the sales of which are reported to be growing.
But then came the Internet and the Web browsers. These are yet another variant on the graphical terminal but using standard protocols and not dependent upon Windows applications. There are a lot of browser compatible servers on the market which will map the Web interfaces onto other applications, which is in fact a GUI version of the old time-shared computing. Again most Web browsers are implemented by running software on a standard PC. Some Web applications actually use interfaces in the PC to Windows application code, making the application dependent on a PC, a very short-sighted approach. The better Web browsers use Java virtual machines to provide centralised support and PC independence. The PC independence will become more and more important as a wide variety of alternative terminals develop.
Thus in competition to the PC for the desktop space there are nowa number ofspecialised "thin-client terminals" They are not true thin-clients, that is best implemented with a PC and remote procedure calls, but they support various mixtures of old terminal applications, Web browser applications and (with a Citrix server) Windows applications. New applications should be built with a Web browser GUI, the others providing a migration path away from the PC.
It is disappointing that this architecture has been so slow in taking off. It is an excellent way to progress and yet provide continuity.< BR>
 
Martin Healey, pioneer development Intel-based computers en c/s-architecture. Director of a number of IT specialist companies and an Emeritus Professor of the University of Wales.