rfc782.txt

RFC 相关的技术文档

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