@heading{Future Terminals} The 'terminal' of the future will be a bitmapped display offering as normal what would currently be regarded as high resolution and supported by mouse and keyboard and, eventually, voice input. The user interface, for whatever application, will be at least of the user friendly standard currently being set by a few micros. It will need to contain significant computing power to supply its graphics but the precise division between a 'terminal', diskless workstation and full powered workstation with local disc support will be less precise than at present and will be determined by the style of application that the user wishes to use. @section{Why remote access?} A reasonable question is why a 'terminal' should be considered at all. Why is our future user not going to be satisfied by his high powered personal workstation with large quantities of disk space? The answer to this question lies in a number of applications that even a powerful workstation cannot handle. @itemise{ Mail - Even with the X.400 standards, workstations in general will not be able to be Message Transfer Agents. The periodical switching off of workstations would cause message delivery to fail as timeouts are short and the problems of an academic institution attempting to handle thousands of MTAs are daunting. Very Large Disk space requirements - the requirements of disk space for databases will probably always outstrip what a user can put on his desk. One common biological database already exceeds 100 Megabytes (???) and other databases such as a library catalogue are in the multi gigabyte size. Compute Servers - although the available power on the desk has grown dramatically so have the requirements. Significant numbers of users will require access to powerful computing resources thus raising questions on how control of such resources can be provided in a user friendly fashion. TP Activities - access to shared data, of a different quality than the databases listed above will require remote access. } @section{Possible Solutions} One method of solving the problems that demand for access as listed above pose is to provide a solution for each case. This is to a large extent the current trend and will cause large duplication of effort. @itemise{ X.400 P7 - The P7 part of the X.400 set of protocols is designed to enable micros and workstations which may only be periodically connected to a network to use electronic mail services. The 1984 set of standards left this area unsolved and a major effort was made in the 1988 revisions and the P7 protocol is the result. However, it now transpires that this protocol is only a partial solution and large areas of the problem, such as the control of messages that the user has read and wishes to keep, have not been solved and either the 1992 revisions are needed or non-standard solutions will be implemented. Database Protocols - manufacturers of databases, such as Oracle, are bringing forward solutions to the distributed database problem. However while solving distributed read access, distributed write access is still awaited. In addition there is no guarentee at all that each major database manufacturer will not produce a unique, non standard set of protocols. TP Protocols - standardisation work on TP protocols is progressing but it is unclear that they could be used outside a narrow, but heavily used, environment. Remote Procedure Call Protocols - a lot of activity is going into RPC style protocols but the work is still relatively immature. } @section{Generalised Windowing Protocols} An alternative solution, at least in part, but trancending all the problem areas are windowing protocols. The two leading alternatives are X Windows and NeWS. @subsection{X Windows} X Windows orginated from Project Athena in MIT but control over the protocol definition belongs to the X Consortium which is widely representative of the computing community. X has been implemented on a wide range of machines both as a host and screen end implementations. Within the past year a number (currently at least 6) of manufacturers have produced 'terminals' which implement X. X is not perfect. It consumes more network resources than NeWS but currently appears to be a clear front runner. @subsection{Network extensible Windowing System} The NeWS protocol was originated by SUN microcompter systems and is firmly controlled by SUN. Although it is possible to licence the code from SUN there is absolutely no guarentee that the protocol will remain stable for any period of time. NeWS is based on the Postscript protocol which is owned and licensed by Adobe systems. As such it is a technically superior product to X, capable of consuming far less networking resource and thus able to run over slower networks than X. @subsection{Standardisation Efforts} The problems over the non-open nature of NeWS has lead to X being picked as a candidate for standardisation by ANSI in the USA. They have produced a draft document which defines X in a standards framework. Although reaction to these moves was orginally hostile outside the USA, a more positive attitude is now being taken. The British Standards Institute, for example, has produced a draft statement which would support X being given the 'Fast Track' procedure within ISO (The fast track procedure is a mechanism whereby an existing 'standard' can be made an ISO standard in, for ISO, a very short time). The conditions which have been laid down by the BSI are that:- @itemise{ A definition of how X maps to the ISO stack is produced Conformance statements for X implementations are produced Language bindings for the X interface are produced }