GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc782
      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 -

  1. 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
/data/webs/external/dokuwiki/data/pages/rfc/rfc782.txt · Last modified: 1992/10/15 21:56 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki