From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc782.txt | 1298 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1298 insertions(+) create mode 100644 doc/rfc/rfc782.txt (limited to 'doc/rfc/rfc782.txt') diff --git a/doc/rfc/rfc782.txt b/doc/rfc/rfc782.txt new file mode 100644 index 0000000..ddf1ce7 --- /dev/null +++ b/doc/rfc/rfc782.txt @@ -0,0 +1,1298 @@ + + + + + + + + + + A Virtual Terminal Management Model + + + + + + RFC 782 + + + + + + prepared for + + Defense Communications Agency + WWMCCS ADP Directorate + Command and Control Technical Center + 11440 Isaac Newton Square + Reston, Virginia 22090 + + + + + + + + + by + Jose Nabielsky + Anita P. Skelton + + + + + + + The MITRE Corporation + MITRE C(3) Division + Washington C(3) Operations + 1820 Dolley Madison Boulevard + + + + + + + + TABLE OF CONTENTS + + + + Page + + +LIST OF ILLUSTRATIONS vi + +1.0 INTRODUCTION 1 +1.1 The Workstation Environment 1 +1.2 Virtual Terminal Management 2 +1.3 The Scope 3 +1.4 Related Work 4 + +2.0 THE VTM MODEL 5 +2.1 The VTM Model Components 7 +2.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 14 +2.3 The Workstation Model 17 + 2.3.1 The Adaptation Unit 17 + 2.3.2 The Executive 18 + +REFERENCES 19 + + + + + + + + + + + + + + + + + + iii + + LIST OF ILLUSTRATIONS + + + + Page + +Figure 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 age +of the inexpensive, yet powerful, microprocessor. Closely resembling +the advances of the 1960's which brought about the transition from +batch processing to time-sharing, this technological trend suggests +the birth of decentralized architectures where the processing power +is shifted closer to the user in the form of intelligent personal +workstations. The virtual terminal model described in this document +caters to this anticipated personal computing environment. + +1.1 The Workstation Environment + + A personal workstation is a computing engine which consists of +hardware and software dedicated to serve a single user. As part of +its architecture, the workstation can invoke the resources of other, +physically separate components, effectively extending this personal +environment well beyond the bounds of the single workstation. + + In this personal environment, processing resources previously +shared among multiple users now become dedicated to a single one, +with a large part of these resources summoned to provide an effective +human-machine interface. As a consequence, modalities of input and +output that were unfeasible under the time-shared regime now become a +part of a conversational language between user and workstation. Due +to the availability of processing cycles, and the closeness of the +user devices to these cycles, the workstation can support interactive +devices, and dialogue modes using these devices, which could not be +afforded before. + + The workstation can provide the user with the mechanisms to +conduct several concurrent conversations with user-agents located +elsewhere in the global architecture. One such mechanism is the +partitioning of the workstation physical display into multiple +logical displays, with one or more of these logical displays +providing a dedicated workspace between user and agent. + + The nature of the conversations on these logical displays need +not be limited to conventional alphanumeric input and output. +Conversations using input tools such as positioning and pointing +devices (e.g., mouse, tablet, and such), and using high-resolution +graphics objects for output (e.g., line drawings, raster blocks and +images, possibly intermixed with text) should be possible on one or +more of these screens. + + Moreover, as long as the technological trend continues in its +predicted path, one can postulate a workstation which could support +by the mid 1980's multi-media conversations using voice and video, + + 1 + + + + + + +synchronized with text and graphics. At present, multi-media +information management (i.e., acquisition, processing, and +dissemination) is an active research area, but eventually it will +become an engineering problem which, when solved, will add a new +dimension to already feasible modes of interaction between user and +workstation. + +1.2 Virtual Terminal Management + + All virtual terminal protocols (VTPs) provide a vehicle for +device-independent, bi-directional, 8-bit byte oriented +communications between two VTP users. Most Vo so by invoking a +device abstraction of real terminals, called a virtual terminal. + + As with a real device, a virtual terminal has a well-defined +architecture with its own character sets and functions. A VTP uses +the architectural features of the virtual terminal to provide a +common language, an intermediate representation, between its two +communicating entities. However a VTP user does not communicate +directly with this virtual terminal. A function of a VTP is the +local mapping between the site-specific order codes and the virtual +terminal domain, thus allowing this adaptation to be transparent to +the VTP users. + + The model of a personal workstation as a dedicated device with +considerable resources affects the way we conceptualize the +architecture of virtual terminals, both in breadth and depth of +function. It also affects the way we view the virtual terminal vis- +a-vis its local correspondents, the personal workstations, and its +remote correspondents, the other virtual terminals. + + This document presents a radical view of virtual terminals as +resource sharing devices. The classical concept of a virtual +terminal as a two-way device with a limited architecture has been +dismissed. Instead, we view a virtual terminal as an n-way device +with multiple correspondents sharing access to its virtual "keyboard" +and "display." In this model, a virtual terminal has two kinds of +correspondents: adaptation units, and other virtual terminals. The +adaptation units serve as interface agents between the virtual +terminal and its users, providing the step transformation between the +user-specific order codes and the virtual terminal interface +language. In turn, the other virtual terminals are cooperating +co-equals of the virtual terminal, interacting with it to maintain +global control and data store synchrony. Resembling the administrator +of a local copy of a distributed data base, the virtual terminal +interacts with the other virtual terminals (the remote data base +managers) and with the local adaptation units (the data base +transformers) to provide read, write, and modify access to its local + + 2 + + + + + + + + + +data store (the local copy of the distributed data base), while +providing concurrency control to maintain a "single user view" when +so desired. + + To communicate with its correspondents, a virtual terminal uses +two virtual languages. In the case where the correspondent is another +virtual terminal, it uses the language of the virtual terminal +protocol; in the case where the correspondent is an adaptation unit, +it uses an interface language closer to the physical architecture of +the end-user, but a virtual language nevertheless. + + In essence, the virtual terminal has become a device in its own +right, free from a single physical realization and also dedicated +ownership. As a result, a single workstation not only may request any +number of virtual terminals, but a number of workstations may +share -- and interact with -- a particular virtual terminal. + + The functional breadth of virtual terminals has been augmented +by the concept of virtual terminal classes. Each class is an +abstraction 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 attendant +operations (the virtual display); a general controlling element (the +virtual controller); and an input selector (the virtual keys). + + Finally, the functional depth of the virtual terminal has been +extended by architectural features previously unavailable. The +virtual terminal becomes a multi-user device with a non-volatile +virtual display available for selective viewing. These concepts are +discussed is some detail in the chapter that follows. + +1.3 The Scope + + An overview of the virtual terminal model and the management of +communicating virtual terminals is presented. A detailed design +description of the data structures and accompanying addressing +functions has been completed. The operations and control mechanisms +are less complete. Before the design is solidified, an initial +mimimal implementation will be made to validate the model. + + This document represents work in progress; current international +interest in virtual terminal protocols has motivated us to submit +this as an example of mechanisms that a virtual terminal should +support. The model provides a framework for supporting device and +processing capabilities not yet commonly available. A virtual +terminal protocol standardization effort may not want to include all +the mechanisms that are described here, but it is our contention that +one should not preclude these extensions for the future. + + 3 + + + + + + + +1.4 Related Work + + The concepts presented in this document are the offspring of +previous work in the area of personal computing, and of user +interfaces to (distributed) systems. The bibliography at the end of +the document collects this material. In particular, we want to +acknowledge the work done at the University of Rochester on virtual +terminals,(6) work which has influenced to a large degree how we +view user interfaces through a display. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 4 + + + + + + + +2.0 THE VTM MODEL + + This section describes a virtual terminal management (VTM) model +whose architecture not only derives from a quest for device- +independent, terminal-oriented communications, but more importantly +from a desire to provide effective human-machine interfaces. + + The VTM architecture is a multi-user structure which spans +several building blocks. The underlying foundation to this structure +is provided by the cooperating virtual terminals. Under the VTM +model, these cooperating virtual terminals are viewed as device +abstractions, all with a common architecture, exchanging virtual +terminal protocol items to update each other's view of the world. +Resting on this foundation lie the adaptation units. Associated with +a single end-user, an adaptation unit provides the step +transformation between user and virtual domains. In a sense the +adaptation unit is also a virtual terminal, although one which is +much closer to the architecture of the end-user. Finally, on top of +this supporting structure are the end-users, the application and +human 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 for +the model and its underlying concepts stems from our desire to +provide 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 major +components: 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 + | + AU1 + + +VT = VIRTUAL TERMINAL +AU = 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 MODEL + + + +The first component embodies the canonical device, while the second +component includes the adaptation unit and its associated +environment. Each component will be described in turn below. + +2.2 The Virtual Terminal Model + + The objective of virtual terminal protocols is to provide the +users of the service with a common, logical view of terminals. The +common user view is attained through a standard, protocol-wide +representation of a canonical terminal, the virtual terminal. This + + 10 + + + + + + + +permits the exchanges between users of the protocol to be free of +device-specific encodings. + + The design postulates an integrated virtual terminal model which +extends the nature and scope of this canonical device in several +important 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 dialogues +in which a single virtual terminal terminates each end of the +communication path. + + We define the virtual terminal as a n-way device where one or +more of the correspondents to this device are local users of the +service, and the remaining correspondents (if any) are peer virtual +terminals. Each correspondent to the virtual terminal has its own +bi-directional path to produce virtual input to, and receive virtual +output from, the virtual terminal. This bi-directional path provides +the vehicle for a virtual terminal session between user and virtual +terminal. 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 virtual +terminal from its physical realization, a single real terminal. +Indeed, a virtual terminal does not map necessarily to just one real +device, but possibly to many real devices. + + The virtual terminal is viewed ultimately as a well-defined data +structure which provides its correspondents with a non-dedicated +virtual terminal service. And these correspondents may have read +only, 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, the +building blocks which make up the virtual terminal, is the result of +a feature extraction of the real terminal that it is tailored to +support. + + We have conceptualized the virtual terminal as a meta-terminal +(i.e., the terminal of terminals). The meta-terminal is composed of +three well-distinguished building blocks: virtual keys, a virtual +controller, and a virtual display. + + + + + 11 + + + + + + + 2.2.2.1 The Virtual Keys. The analog of the virtual keys is +the physical keyboard of real terminals. However, while the keys of +a physical terminal are controlled by a single manual process, these +virtual keys can be activated by multiple, concurrent entities (the +virtual terminal correspondents). Each correspondent of the virtual +terminal, be it a user of the service or a peer virtual terminal, has +its input stream to the meta-terminal terminated at the virtual keys. +The virtual keys provide the control of access of input streams to +the meta-terminal. + + + 2.2.2.2 The Virtual Controller. The virtual controller +provides virtual terminal session management. It manages the +establishment and termination of a virtual terminal session with a +correspondent; supports the possible negotiation and renegotiation of +the session attributes; and enables the deactivation and later +activation of the session. The virtual controller also provides +virtual terminal signalling control by managing the out-of-band +signals addressed to the virtual terminal. + + + 2.2.2.3 The Virtual Display. The virtual display is the +dynamic component in the meta-terminal organization. For each class +of real device (e.g. stream, line, page, or graphics-oriented +devices) there is a corresponding virtual terminal class. The +organization of the virtual terminal data structure is class- +specific. A virtual terminal models a particular terminal class when +it is 'fitted' with the proper data structure manager or virtual +display. This binding need not be static (e.g., a line-class +specialist, 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 with +the meta-terminal and performs operations on the control and data +elements of the structure. As a direct consequence of these +operations on the meta-terminal data structure, the virtual display +may generate display updates to one, some, or all of the +correspondents. All virtual terminal output streams originate at the +virtual 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 a +single, wide-scoped virtual display with a character-oriented data +structure by constraining it to conform to the model of the device +class (e.g., line-oriented devices must be constrained to line-access +rules). For non character-oriented virtual devices (e.g., graphics +devices), an altogether different virtual display must be used with + + 12 + + + + + + +properties better suited for the new domain (e.g., a graphics virtual +display based on a structured display file). + + 2.2.3 Virtual Terminal Architecture + + The commands, and associated parameters, which are available to +the users of the virtual terminal constitute the virtual terminal +architecture. The commands available to a user -- to request the +virtual controller to establish, abort, or close a session, and +discard, suspend, or resume output -- remain invariant to the virtual +terminal class. However, as one would expect, the user interface to +the 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-extended +virtual display, and the concept of virtual display windows. Each of +these concepts are a part of the meta-terminal architecture because +they 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 a +standard, protocol-wide name which we call a communication variable. +The communication variable is a part of the header of each command to +the virtual terminal (i.e. protocol item). It permits better +management of the virtual terminal command name space, and also +provides the virtual keys with an easy mechanism to select the +destination of the request. It must be noted that nothing in the +model 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 which +alleviates the problems of device selection and command name +allocation in the case of such extensions. + + + 2.2.3.2 Virtual Display with File Extension. The virtual +display is the immediate manager of the meta-terminal data structure. +When the virtual display is provided with an I/O file extension, it +is possible to introduce the concept of a stable-store data +structure, a data structure whose contents are stored in backing +store (e.g., disk). If the virtual display is provided with this +file extension capability (a local option with no end-to-end +significance), then the meta-terminal data structure inherits the +spatial and temporal attributes (dimensions and time-to-live) of the +associated file. Such a virtual display, coupled with the concept of +virtual display windows below, provides the users of the service with +a very powerful tool. + + + 13 + + + + + + + 2.2.3.3 Virtual Display Windows. To communicate with a virtual +terminal, each real device uses an adaptation unit as its interface +entity (this adaptation unit is a part of the workstation model, see +section 2.3). What is important to note is that the adaptation unit +provides the transition between the device-specific domain, the +device workspace, and the virtual domain, the master workspace (see +Figure 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 master +workspace, only in a portion of it. As part of its session +attributes, each adaptation unit has a window, a rectangular region +in the virtual display, which delimits its area of interest in the +master. This portion of the master domain will be referred as the +instance workspace. Then, for each adaptation unit, there is an +instance workspace whose spatial attributes (dimension and position +within 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 virtual +terminal is concerned, each instance workspace defines a "real" +terminal, although in fact it is just an intermediate representation +of the real device. In essence, the instance workspace is the +coordinate space where both virtual terminal and adaptation unit +rendezvous. (See section 2.3 for a discussion of how this instance +workspace is mapped onto the device workspace). + + The window dimensions are the exclusive choice of the adaptation +unit that owns it. With these dimensions the adaptation unit +specifies to the virtual terminal how much of the master is to be +viewed; data elements not contained within the boundaries of the +window are clipped. Varying the dimension of the window results in +corresponding changes on the amount of the master that is viewed. + + In contrast, the position of the window on the master might not +be under direct control of the adaptation unit. To understand the +dynamics of a window, we introduce the notion of a master cursor and +an instance cursor. The master cursor is a read/write pointer, which +is a part of the virtual display architecture. In turn, the instance +cursor is a pointer owned by the adaptation unit, which is a part of +the state information maintained by the virtual display. Normally, +both master and instance cursors are bound together so that motion of +one cursor translates into an equivalent motion of the other. As +long as the adaptation unit does not explicitly unbind its instance +cursor from the master cursor, the active region of the master (i.e., +the position where the master cursor lies) is guaranteed to be always +within the instance space, and thus viewable. This means that +certain operations on the virtual display will implicitly relocate +the window of an adaptation unit within the bounds of the master +workspace to insure the tracking of the master cursor. (The actual +algorithm which enforces this tracking rule, called the viewing +algorithm, has not been included here.) This window relocation is + + + 16 + + + + + + +viewed at the real terminal as either vertical or horizontal +scrolling. + + However, an adaptation unit has the choice to bypass this rule +by detaching its instance cursor from the master, effectively getting +complete control of its cursor to view other portions of the master +space. If the virtual display has an I/O file extension, then the +adaptation unit can pan its window on the file-extended space well +beyond the present contents of the master space. Therein lies the +power of a stable-store data structure when coupled with the concept +of windowing. + +2.3 The Workstation Model + + The workstation model is composed of one or more adaptation +units, and a workstation monitor, which we will call the executive. +Each will be described in turn below. In addition, the model +includes input and output handlers, and an underlying multi-tasking +operating 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 different +such instances per physical workstation, then potentially many +adaptation units will be co-located at a workstation. + + The adaptation unit can be viewed as the workstation agent which +provides the mapping between instance workspace and device workspace. +To define this mapping, we introduce the notion of a viewport as a +rectangular area of the physical screen allocated for the viewing of +a virtual terminal instance. An adaptation unit has the task of +mapping the totality of the instance workspace onto the viewport, a +mapping which is a device-specific concern totally removed from the +domain of discourse of the virtual terminal. Thus the position of +the viewport determines the relocation of the selected data structure +elements on the viewing unit, and the viewport dimensions a +(potential) scaling transformation. + + The adaptation unit also produces virtual input to the virtual +terminal by translating the user input into virtual terminal +commands. It implements the service side of the interface to the +virtual terminal. + + + + + + + 17 + + + + + + + 2.3.2 The Executive + + This conceptual entity performs the task and resource management +required to create and destroy virtual terminal instances, and to map +these virtual terminal instances to the screen viewports. + + It must provide at least a minimal user command interface so +that its tools may be accessed (one of them being the management of +screen real estate). + + Finally, the executive provides the mechanism for the end-user +to switch viewport contexts through the use of some input device +(e.g., function key, pointing or positioning device). Following a +user interaction which indicates a change of context, the executive +makes the newly selected virtual terminal instance the dedicated +owner of the input devices. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 18 + + + + + + + REFERENCES + + + +1. 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, Scott Fahlman, 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. Jon Postel and Dave Crocker. "TELNET Remote Controlled + Transmission and Echoing Option," ARPA Network Working Group RFC + 726, 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 + + + + + + -- cgit v1.2.3