Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
UNKNOWN
A Virtual Terminal Management ModelRFC 782 prepared for Defense Communications Agency WWMCCS ADP Directorate Command and Control Technical Center 11440 Isaac Newton Square Reston, Virginia 22090by Jose Nabielsky Anita P. Skelton The MITRE Corporation MITRE C(3) Division Washington C(3) Operations 1820 Dolley Madison Boulevard
TABLE OF CONTENTS PageLIST OF ILLUSTRATIONS vi1.0 INTRODUCTION 11.1 The Workstation Environment 11.2 Virtual Terminal Management 21.3 The Scope 31.4 Related Work 42.0 THE VTM MODEL 52.1 The VTM Model Components 72.2 The Virtual Terminal Model 10 2.2.1 Virtual Terminal Connectivity 11 2.2.2 Virtual Terminal Organization 11 2.2.2.1 The Virtual Keys 12 2.2.2.2 The Virtual Controller 12 2.2.2.3 The Virtual Display 12 2.2.3 Virtual Terminal Architecture 13 2.2.3.1 Communication Variables 13 2.2.3.2 Virtual Display with File Extension 13 2.2.3.3 Virtual Display Windows 142.3 The Workstation Model 17 2.3.1 The Adaptation Unit 17 2.3.2 The Executive 18REFERENCES 19 iii
LIST OF ILLUSTRATIONS PageFigure Number 2.1 The Virtual Terminal Model 7 2.2 The Workstation Model 8 2.3 VT 0 (expanded from previous figure) 9 2.4 The Domains 14 v
1.0 INTRODUCTION Recent advances in micro-electronics have brought us to the ageof the inexpensive, yet powerful, microprocessor. Closely resemblingthe advances of the 1960's which brought about the transition frombatch processing to time-sharing, this technological trend suggeststhe birth of decentralized architectures where the processing poweris shifted closer to the user in the form of intelligent personalworkstations. The virtual terminal model described in this documentcaters to this anticipated personal computing environment.1.1 The Workstation Environment A personal workstation is a computing engine which consists ofhardware and software dedicated to serve a single user. As part ofits architecture, the workstation can invoke the resources of other,physically separate components, effectively extending this personalenvironment well beyond the bounds of the single workstation. In this personal environment, processing resources previouslyshared among multiple users now become dedicated to a single one,with a large part of these resources summoned to provide an effectivehuman-machine interface. As a consequence, modalities of input andoutput that were unfeasible under the time-shared regime now become apart of a conversational language between user and workstation. Dueto the availability of processing cycles, and the closeness of theuser devices to these cycles, the workstation can support interactivedevices, and dialogue modes using these devices, which could not beafforded before. The workstation can provide the user with the mechanisms toconduct several concurrent conversations with user-agents locatedelsewhere in the global architecture. One such mechanism is thepartitioning of the workstation physical display into multiplelogical displays, with one or more of these logical displaysproviding a dedicated workspace between user and agent. The nature of the conversations on these logical displays neednot be limited to conventional alphanumeric input and output.Conversations using input tools such as positioning and pointingdevices (e.g., mouse, tablet, and such), and using high-resolutiongraphics objects for output (e.g., line drawings, raster blocks andimages, possibly intermixed with text) should be possible on one ormore of these screens. Moreover, as long as the technological trend continues in itspredicted path, one can postulate a workstation which could supportby the mid 1980's multi-media conversations using voice and video, 1
synchronized with text and graphics. At present, multi-mediainformation management (i.e., acquisition, processing, anddissemination) is an active research area, but eventually it willbecome an engineering problem which, when solved, will add a newdimension to already feasible modes of interaction between user andworkstation.1.2 Virtual Terminal Management All virtual terminal protocols (VTPs) provide a vehicle fordevice-independent, bi-directional, 8-bit byte orientedcommunications between two VTP users. Most Vo so by invoking adevice abstraction of real terminals, called a virtual terminal. As with a real device, a virtual terminal has a well-definedarchitecture with its own character sets and functions. A VTP usesthe architectural features of the virtual terminal to provide acommon language, an intermediate representation, between its twocommunicating entities. However a VTP user does not communicatedirectly with this virtual terminal. A function of a VTP is thelocal mapping between the site-specific order codes and the virtualterminal domain, thus allowing this adaptation to be transparent tothe VTP users. The model of a personal workstation as a dedicated device withconsiderable resources affects the way we conceptualize thearchitecture of virtual terminals, both in breadth and depth offunction. It also affects the way we view the virtual terminal vis-a-vis its local correspondents, the personal workstations, and itsremote correspondents, the other virtual terminals. This document presents a radical view of virtual terminals asresource sharing devices. The classical concept of a virtualterminal as a two-way device with a limited architecture has beendismissed. Instead, we view a virtual terminal as an n-way devicewith multiple correspondents sharing access to its virtual "keyboard"and "display." In this model, a virtual terminal has two kinds ofcorrespondents: adaptation units, and other virtual terminals. Theadaptation units serve as interface agents between the virtualterminal and its users, providing the step transformation between theuser-specific order codes and the virtual terminal interfacelanguage. In turn, the other virtual terminals are cooperatingco-equals of the virtual terminal, interacting with it to maintainglobal control and data store synchrony. Resembling the administratorof a local copy of a distributed data base, the virtual terminalinteracts with the other virtual terminals (the remote data basemanagers) and with the local adaptation units (the data basetransformers) to provide read, write, and modify access to its local 2
data store (the local copy of the distributed data base), whileproviding concurrency control to maintain a "single user view" whenso desired. To communicate with its correspondents, a virtual terminal usestwo virtual languages. In the case where the correspondent is anothervirtual terminal, it uses the language of the virtual terminalprotocol; in the case where the correspondent is an adaptation unit,it uses an interface language closer to the physical architecture ofthe end-user, but a virtual language nevertheless. In essence, the virtual terminal has become a device in its ownright, free from a single physical realization and also dedicatedownership. As a result, a single workstation not only may request anynumber of virtual terminals, but a number of workstations mayshare -- and interact with -- a particular virtual terminal. The functional breadth of virtual terminals has been augmentedby the concept of virtual terminal classes. Each class is anabstraction of a particular device architecture. There are stream,line, logical page, physical page, and graphics virtual terminals,all made up of: a class-constrained data structure and its attendantoperations (the virtual display); a general controlling element (thevirtual controller); and an input selector (the virtual keys). Finally, the functional depth of the virtual terminal has beenextended by architectural features previously unavailable. Thevirtual terminal becomes a multi-user device with a non-volatilevirtual display available for selective viewing. These concepts arediscussed is some detail in the chapter that follows.1.3 The Scope An overview of the virtual terminal model and the management ofcommunicating virtual terminals is presented. A detailed designdescription of the data structures and accompanying addressingfunctions has been completed. The operations and control mechanismsare less complete. Before the design is solidified, an initialmimimal implementation will be made to validate the model. This document represents work in progress; current internationalinterest in virtual terminal protocols has motivated us to submitthis as an example of mechanisms that a virtual terminal shouldsupport. The model provides a framework for supporting device andprocessing capabilities not yet commonly available. A virtualterminal protocol standardization effort may not want to include allthe mechanisms that are described here, but it is our contention thatone should not preclude these extensions for the future. 3
1.4 Related Work The concepts presented in this document are the offspring ofprevious work in the area of personal computing, and of userinterfaces to (distributed) systems. The bibliography at the end ofthe document collects this material. In particular, we want toacknowledge the work done at the University of Rochester on virtualterminals,(6) work which has influenced to a large degree how weview user interfaces through a display. 4
2.0 THE VTM MODEL This section describes a virtual terminal management (VTM) modelwhose architecture not only derives from a quest for device-independent, terminal-oriented communications, but more importantlyfrom a desire to provide effective human-machine interfaces. The VTM architecture is a multi-user structure which spansseveral building blocks. The underlying foundation to this structureis provided by the cooperating virtual terminals. Under the VTMmodel, these cooperating virtual terminals are viewed as deviceabstractions, all with a common architecture, exchanging virtualterminal protocol items to update each other's view of the world.Resting on this foundation lie the adaptation units. Associated witha single end-user, an adaptation unit provides the steptransformation between user and virtual domains. In a sense theadaptation unit is also a virtual terminal, although one which ismuch closer to the architecture of the end-user. Finally, on top ofthis supporting structure are the end-users, the application andhuman processes, all interacting towards a common goal. Before embarking on a description of the VTM model components,we present the set of capabilities the VTM model provides its end-users, either human or application. After all, the motivation forthe model and its underlying concepts stems from our desire toprovide productive user environments. HUMAN <---> WORKSTATION o Multiplexing the workstation physical display both in time and space. The workstation assigns to each user conversation a logical terminal with a well-distinguished logical display. Under the user control, the workstation maps these logical displays on non-overlapping areas of the physical display, providing a dedicated workspace between user and correspondents. Limited only by the area of the display, many logical displays could be mapped at one time, each providing display updates when so required. Since the area of the display is a scarce resource, not all logical displays need be mapped at the same time. Therefore, the workstation may roll-out and roll-in selected displays under the user control, thereby also multiplexing the physical display in time. o Multiplexing the workstation input devices in time. 5
The input devices always map to a single user conversation (i.e., a single logical terminal). However, the user can select a new logical terminal by some well-defined interaction (e.g., depressing a function key, using a pointing device, and such), effectively switching the ownership of the input tools. o Concurrent multi-mode use of the workstation. The capabilities of the workstation limit the scope and character of the individual conversations. If the workstation supports rubout processing (i.e., erase operations on lines and characters), then the logical terminals can be independent, scrolling "terminals," some page-oriented, others line-oriented. If the architecture of the workstation supports graphics objects as primitive objects then so can the individual logical terminals. As a consequence, while some logical terminal displays may be dedicated to alphanumeric output, others may include raster graphics and imaging data together with positioned text. o The sharing of a single logical terminal among several users. Several end-users may link to a single logical terminal. All linked parties are viewed by the shared "device" as both input sources and output sinks. As a consequence this device sharing need not be limited only to the sharing of device output. In general, each linked party may have full read and write access to the logical terminal, if it so desires. o Selective viewing on a logical terminal display. In the user's view, a logical terminal display is a user- specified window on a potentially larger structure, the "device" display. This window provides the "peephole" through which the device display is viewed. The portion of the device display mapped on this window is not limited to its "present contents." Under the user control, the workstation may invoke the viewing of past activity on a logical terminal display when the device display is I/O file-extended. Since the window mechanism is an integral part of the device architecture, it is available on all logical terminal displays. Furthermore, the viewing of past activity does not affect others sharing access to the device. 6
o Discarding, suspending, and resuming the output of a logical terminal always under user control. As part of the user interface, the workstation provides simple "keys" through which the user controls the output on a logical terminal display. These workstation "keys" need not be physical keys, but could be other input tools used for this purpose (e.g., analog dials, hit-sensitive areas on the physical display, and such). In any event, through the auspices of the workstation, the user's control requests translate into the proper commands to the "device" associated with the logical terminal. APPLICATION <---> ADAPTATION UNIT o A logical view of real devices. For each real terminal architecture, one canonical representation: a logical device. o For a particular logical device, several possible interaction paradigms. Some logical devices are intrinsically half-duplex (e.g., a page-oriented logical device), some are full-duplex (e.g., communicating processes using a stream-oriented logical device), and some may be either half or full-duplex (e.g., a line-oriented logical device). Some full-duplex logical devices can provide no echoing, remote echoing, or local echoing. Those that interface with applications that support command completion (e.g., command-line interpreters) can shift the locus of echoing as a function of a dynamic break character set. o One application communicating with several logical devices. As part of an application's model of interaction, an application may "own" several logical devices. For example, an editor could use a line-oriented logical device to gather top-level commands, and a page-oriented logical device to provide editing workspace.2.1 The VTM Model Components The virtual terminal management model consists of two majorcomponents: the virtual terminal model, and the workstation model(see Figures 2.1, 2.2, and 2.3 respectively). 7
AU1 | AU0 | AU2 | | | _______________ | | | VT2 | | | | | _______________ | _______________ | | |----AU0 |_______| VT0 | |_______| | | | |----AU1 | _______________ | ________________ | | | | | VT1 | | | ________________ | | | AU0 | AU2 | AU1VT = VIRTUAL TERMINALAU = ADAPTATION UNIT FIGURE 2.1 - THE VIRTUAL TERMINAL MODEL 8
___ ___ ___ ___ |VT1||VT2| |VT1||VT2| ____ _____ _____ ____ | | | | __|_____|_________________|_____|__ | | | | | | | | | REMOTE | -CONTROLLER-| REMOTE | | KEYS | | DISPLAYS | | | | | | VIRTUAL | | DATA | | KEYS | | STORE | | |<----------->| | | LOCAL | | LOCAL | | KEYS | | DISPLAYS | | | | | __|_____|__________________|_____|__ | | | | ____ ____ _____ ____ |AU0||AU1| |AU0||AU1| ____ ____ _____ ____ FIGURE 2.2 -- VT0 (expanded from previous figure) 9
+--------------------+ | | o-|-------------------| | EXECUTIVE | |--------------------| Screen +-------+ o-|--------------------| +-----++---------+ /|OUTPUT | | ADAPTATION UNIT 0 |<---->| VT0 ||EXECUTIVE| / | |<---|--------------------| +-----+|---------| / |HANDLER| o-|--------------------| +-----+| AU0 | / |-------| | ADAPTATION UNIT 1 |<---->| VT1 ||---------| / | INPUT | |--------------------| +-----+| AU1 |/ | | o-|--------------------||---------| |HANDLER| | . || | | /--|o | . |~ ~ +-------+ ~ . ~~ ~ / ~ ~|---------| / o-|--------------------| +-----+| AUK | / | ADAPTATION UNIT K |<---->| VTK |+---------+ / +--------------------+ +-----+ / | |+---------+ / +--------------------+|Keyboard | /+---------+ /|[] [] [] | /|[] [] [] |/+---------+ FIGURE 2.3 - THE WORKSTATION MODELThe first component embodies the canonical device, while the secondcomponent includes the adaptation unit and its associatedenvironment. Each component will be described in turn below.2.2 The Virtual Terminal Model The objective of virtual terminal protocols is to provide theusers of the service with a common, logical view of terminals. Thecommon user view is attained through a standard, protocol-widerepresentation of a canonical terminal, the virtual terminal. This 10
permits the exchanges between users of the protocol to be free ofdevice-specific encodings. The design postulates an integrated virtual terminal model whichextends the nature and scope of this canonical device in severalimportant ways. The major aspects of the model, its connectivity,its organization, and its architecture are described below. 2.2.1 Virtual Terminal Connectivity Most virtual terminal protocols only cater to two-way dialoguesin which a single virtual terminal terminates each end of thecommunication path. We define the virtual terminal as a n-way device where one ormore of the correspondents to this device are local users of theservice, and the remaining correspondents (if any) are peer virtualterminals. Each correspondent to the virtual terminal has its ownbi-directional path to produce virtual input to, and receive virtualoutput from, the virtual terminal. This bi-directional path providesthe vehicle for a virtual terminal session between user and virtualterminal. Globally, the cooperating virtual terminals and these bi-directional paths span a dendritic (tree-like) topology. It is important to note that we have decoupled the virtualterminal from its physical realization, a single real terminal.Indeed, a virtual terminal does not map necessarily to just one realdevice, but possibly to many real devices. The virtual terminal is viewed ultimately as a well-defined datastructure which provides its correspondents with a non-dedicatedvirtual terminal service. And these correspondents may have readonly, write only, or read/write access rights to this data structure. 2.2.2 Virtual Terminal Organization The virtual terminal is an abstraction; its organization, thebuilding blocks which make up the virtual terminal, is the result ofa feature extraction of the real terminal that it is tailored tosupport. We have conceptualized the virtual terminal as a meta-terminal(i.e., the terminal of terminals). The meta-terminal is composed ofthree well-distinguished building blocks: virtual keys, a virtualcontroller, and a virtual display. 11
2.2.2.1 The Virtual Keys. The analog of the virtual keys isthe physical keyboard of real terminals. However, while the keys ofa physical terminal are controlled by a single manual process, thesevirtual keys can be activated by multiple, concurrent entities (thevirtual terminal correspondents). Each correspondent of the virtualterminal, be it a user of the service or a peer virtual terminal, hasits input stream to the meta-terminal terminated at the virtual keys.The virtual keys provide the control of access of input streams tothe meta-terminal. 2.2.2.2 The Virtual Controller. The virtual controllerprovides virtual terminal session management. It manages theestablishment and termination of a virtual terminal session with acorrespondent; supports the possible negotiation and renegotiation ofthe session attributes; and enables the deactivation and lateractivation of the session. The virtual controller also providesvirtual terminal signalling control by managing the out-of-bandsignals addressed to the virtual terminal. 2.2.2.3 The Virtual Display. The virtual display is thedynamic component in the meta-terminal organization. For each classof real device (e.g. stream, line, page, or graphics-orienteddevices) there is a corresponding virtual terminal class. Theorganization of the virtual terminal data structure is class-specific. A virtual terminal models a particular terminal class whenit is 'fitted' with the proper data structure manager or virtualdisplay. This binding need not be static (e.g., a line-classspecialist, and so forth), but could be result of decisions made at"run-time" by applying the principle of negotiated options. The virtual display manages the data structure associated withthe meta-terminal and performs operations on the control and dataelements of the structure. As a direct consequence of theseoperations on the meta-terminal data structure, the virtual displaymay generate display updates to one, some, or all of thecorrespondents. All virtual terminal output streams originate at thevirtual display. Different virtual terminal classes are spawned by different"kinds" of virtual displays, and this is realized in one of two ways.For character-oriented virtual devices, it is possible to use asingle, wide-scoped virtual display with a character-oriented datastructure by constraining it to conform to the model of the deviceclass (e.g., line-oriented devices must be constrained to line-accessrules). For non character-oriented virtual devices (e.g., graphicsdevices), an altogether different virtual display must be used with 12
properties better suited for the new domain (e.g., a graphics virtualdisplay based on a structured display file). 2.2.3 Virtual Terminal Architecture The commands, and associated parameters, which are available tothe users of the virtual terminal constitute the virtual terminalarchitecture. The commands available to a user -- to request thevirtual controller to establish, abort, or close a session, anddiscard, suspend, or resume output -- remain invariant to the virtualterminal class. However, as one would expect, the user interface tothe virtual display depends on the nature of this data structure. Three important architectural features of the meta-terminal are:the concept of communication variables, the notion of a file-extendedvirtual display, and the concept of virtual display windows. Each ofthese concepts are a part of the meta-terminal architecture becausethey are apparent to the users of the virtual terminal. 2.2.3.1 Communication Variables. Each component of the meta-terminal (i.e., virtual keys, controller, display) is assigned astandard, protocol-wide name which we call a communication variable.The communication variable is a part of the header of each command tothe virtual terminal (i.e. protocol item). It permits bettermanagement of the virtual terminal command name space, and alsoprovides the virtual keys with an easy mechanism to select thedestination of the request. It must be noted that nothing in themodel precludes the addition of more virtual entities to the meta-terminal, such as auxiliary virtual devices and signalling devices.The use of communication variables provides a naming hierarchy whichalleviates the problems of device selection and command nameallocation in the case of such extensions. 2.2.3.2 Virtual Display with File Extension. The virtualdisplay is the immediate manager of the meta-terminal data structure.When the virtual display is provided with an I/O file extension, itis possible to introduce the concept of a stable-store datastructure, a data structure whose contents are stored in backingstore (e.g., disk). If the virtual display is provided with thisfile extension capability (a local option with no end-to-endsignificance), then the meta-terminal data structure inherits thespatial and temporal attributes (dimensions and time-to-live) of theassociated file. Such a virtual display, coupled with the concept ofvirtual display windows below, provides the users of the service witha very powerful tool. 13
2.2.3.3 Virtual Display Windows. To communicate with a virtualterminal, each real device uses an adaptation unit as its interfaceentity (this adaptation unit is a part of the workstation model, seesection 2.3). What is important to note is that the adaptation unitprovides the transition between the device-specific domain, thedevice workspace, and the virtual domain, the master workspace (seeFigure 2.4). 14
| | | | VIRTUAL TERMINAL | ADAPTATION UNIT | |<------------------------------->|<--------------------------------->| | DOMAIN | DOMAIN | | | | + - - - - - - - - - + + - - - - - - - - - + - - - - - - - - - | +---> x(m) | | | / /| | | | | x(i) | / / | | v y(m) | | +---------------> | - - - - - - - - - | | | | | | | | +------------+ | | | +--------------+ | | | | | | | VIEWPORT 1 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A<---------|--|-----|-|->A | | | | | | | | | / \ | | | | | | | | | <--------|--|---|-|-> \ | | | | | | | | | / | | | | \ | | | | <---|-|--|+ | | A | | | | \ | | | +------------+ | || | | | | | | \ | | | | || | | WINDOW | | | | \ | | | +------------+ | || | | | | | | \ | | | | VIEWPORT 2 | | || | | | | | |-----------\--+ | | | | | || | | | | | | \ | | | | | || | +--------------+ | | v y(i) \ | | +------------+ | || | | | \ | | | / | | | | \ | | | | | | | \| - - - - - - - - | | / | | / | | | | + - -/- - - - - - - + + - - -/- - - - - - +\ | | | / / \ - - - - - - - - | / / \ | KEYBOARD | | MASTER WORKSPACE INSTANCE WORKSPACE \ + - - - - - - - + | <-/ [] [] [] /| | / [] [] [] / | | + - - - - - - - - + | | PHYSICAL DEVICE WORKSPACE --+ FIGURE 2.4 -- THE DOMAINS 15
However a device need not be interested in the whole masterworkspace, only in a portion of it. As part of its sessionattributes, each adaptation unit has a window, a rectangular regionin the virtual display, which delimits its area of interest in themaster. This portion of the master domain will be referred as theinstance workspace. Then, for each adaptation unit, there is aninstance workspace whose spatial attributes (dimension and positionwithin the master) are those of its window definition. All adaptation units communicate with the virtual terminal"relative" to their own instance workspace. As far as the virtualterminal is concerned, each instance workspace defines a "real"terminal, although in fact it is just an intermediate representationof the real device. In essence, the instance workspace is thecoordinate space where both virtual terminal and adaptation unitrendezvous. (Seesection 2.3 for a discussion of how this instanceworkspace is mapped onto the device workspace). The window dimensions are the exclusive choice of the adaptationunit that owns it. With these dimensions the adaptation unitspecifies to the virtual terminal how much of the master is to beviewed; data elements not contained within the boundaries of thewindow are clipped. Varying the dimension of the window results incorresponding changes on the amount of the master that is viewed. In contrast, the position of the window on the master might notbe under direct control of the adaptation unit. To understand thedynamics of a window, we introduce the notion of a master cursor andan instance cursor. The master cursor is a read/write pointer, whichis a part of the virtual display architecture. In turn, the instancecursor is a pointer owned by the adaptation unit, which is a part ofthe state information maintained by the virtual display. Normally,both master and instance cursors are bound together so that motion ofone cursor translates into an equivalent motion of the other. Aslong as the adaptation unit does not explicitly unbind its instancecursor from the master cursor, the active region of the master (i.e.,the position where the master cursor lies) is guaranteed to be alwayswithin the instance space, and thus viewable. This means thatcertain operations on the virtual display will implicitly relocatethe window of an adaptation unit within the bounds of the masterworkspace to insure the tracking of the master cursor. (The actualalgorithm which enforces this tracking rule, called the viewingalgorithm, has not been included here.) This window relocation is 16
viewed at the real terminal as either vertical or horizontalscrolling. However, an adaptation unit has the choice to bypass this ruleby detaching its instance cursor from the master, effectively gettingcomplete control of its cursor to view other portions of the masterspace. If the virtual display has an I/O file extension, then theadaptation unit can pan its window on the file-extended space wellbeyond the present contents of the master space. Therein lies thepower of a stable-store data structure when coupled with the conceptof windowing.2.3 The Workstation Model The workstation model is composed of one or more adaptationunits, and a workstation monitor, which we will call the executive.Each will be described in turn below. In addition, the modelincludes input and output handlers, and an underlying multi-taskingoperating system of unspecified architecture. 2.3.1 The Adaptation Unit An adaptation unit embodies an instance of a virtual terminal,and since the workstation model postulates possibly many differentsuch instances per physical workstation, then potentially manyadaptation units will be co-located at a workstation. The adaptation unit can be viewed as the workstation agent whichprovides the mapping between instance workspace and device workspace.To define this mapping, we introduce the notion of a viewport as arectangular area of the physical screen allocated for the viewing ofa virtual terminal instance. An adaptation unit has the task ofmapping the totality of the instance workspace onto the viewport, amapping which is a device-specific concern totally removed from thedomain of discourse of the virtual terminal. Thus the position ofthe viewport determines the relocation of the selected data structureelements on the viewing unit, and the viewport dimensions a(potential) scaling transformation. The adaptation unit also produces virtual input to the virtualterminal by translating the user input into virtual terminalcommands. It implements the service side of the interface to thevirtual terminal. 17
2.3.2 The Executive This conceptual entity performs the task and resource managementrequired to create and destroy virtual terminal instances, and to mapthese virtual terminal instances to the screen viewports. It must provide at least a minimal user command interface sothat its tools may be accessed (one of them being the management ofscreen real estate). Finally, the executive provides the mechanism for the end-userto switch viewport contexts through the use of some input device(e.g., function key, pointing or positioning device). Following auser interaction which indicates a change of context, the executivemakes the newly selected virtual terminal instance the dedicatedowner of the input devices. 18
REFERENCES1. R. Bisbey II and D. Hollingworth. "A distributable, display- device-independent vector graphics system for the military command and control environment," Information Sciences Institute, Marina del Rey, California, April 1978.2. Alan Branden, et al."Lisp Machine Project Report," Artificial Intelligence Laboratory, Massachusetts Institute of Technology, AIM 444, August 1977.3. John Day."TELNET Data Entry Terminal Option," ARPA Network Working Group RFC 732, Network Information Center, SRI International, September 1977.4. Douglas Gerhart and D. L. Parnas.WINDOW A formally specified graphics based text editor, Computer Science Department, Carnegie-Mellon University, June 1973.5. B. W. Lampson and R. F. Sproull, "An Open Operating System for a Single-User Machine," Proc 7th Symposium on Operating Systems Principles 9-17, ACM, December 1979.6. Keith Lantz.Uniform Interfaces for Distributed Systems, Ph.D. thesis, University of Rochester, Rochester, N.Y., May 1980.7. Mathis, J.E., et al, "Terminal Interface Unit Notebook,"Volume 2, ARPA Order No. 2302, SRI Project No. 6933, SRI International, Menlo Park, California, 1979.8. Allen Newell, ScottFahlman, Bob Sproull. "A Proposal for Personal Scientific Computing," Department of Computer Science, Carnegie-Mellon University, July 1979 (DRAFT).9. "PERQ,"Three Rivers Computer Corp., 160 N. Craig St., Pittsburgh, Pa. 15213.10. JonPostel and Dave Crocker. "TELNET Remote Controlled Transmission and Echoing Option," ARPA Network Working GroupRFC726, Network Information Center, SRI International, March 1977. 19
11. John F. Shoch and Jon A. Hupp."Notes on the 'Worm' programs - - some early experience with a distributed computation," Xerox Palo Alto Research Center publication SSL-80-3. Presented at the Workshop on Fundamental Issues in Distributed Computing, ACM/SIGOPS and ACM/SIGPLAN, December 1980.12. R. F. Sproull and E. L. Thomas.A network graphics protocol, Computer Graphics 8(3), Fall 1974.13. C. P. Thacker, E. M. McCreight, B. W. Lampson,R. F. Sproull, and D. R. Boggs. "Alto: A Personal Computer." D. Siewiorek, C. G. Bell, and A. Newell, Computer Structures Readings and Examples, editors, second edition, McGraw-Hill, 1979. 20
[8]ページ先頭