As per Relevance of the word structure, we have this rfc below:
A Virtual Terminal Management
RFC 782
prepared for
Defense Communications
WWMCCS ADP
Command and Control Technical
11440 Isaac Newton
Reston, Virginia 22090
Jose
Anita P.
The MITRE
MITRE C(3)
Washington C(3)
1820 Dolley Madison
TABLE OF
LIST OF ILLUSTRATIONS
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
LIST OF
Figure
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
1.0
Recent advances in micro-electronics have brought us to the
of the inexpensive, yet powerful, microprocessor. Closely
the advances of the 1960's which brought about the transition
batch processing to time-sharing, this technological trend
the birth of decentralized architectures where the processing
is shifted closer to the user in the form of intelligent
workstations. The virtual terminal model described in this
caters to this anticipated personal computing environment
1.1 The Workstation
A personal workstation is a computing engine which consists
hardware and software dedicated to serve a single user. As part
its architecture, the workstation can invoke the resources of other
physically separate components, effectively extending this
environment well beyond the bounds of the single workstation
In this personal environment, processing resources
shared among multiple users now become dedicated to a single one
with a large part of these resources summoned to provide an
human-machine interface. As a consequence, modalities of input
output that were unfeasible under the time-shared regime now become
part of a conversational language between user and workstation.
to the availability of processing cycles, and the closeness of
user devices to these cycles, the workstation can support
devices, and dialogue modes using these devices, which could not
afforded before
The workstation can provide the user with the mechanisms
conduct several concurrent conversations with user-agents
elsewhere in the global architecture. One such mechanism is
partitioning of the workstation physical display into
logical displays, with one or more of these logical
providing a dedicated workspace between user and agent
The nature of the conversations on these logical displays
not be limited to conventional alphanumeric input and output
Conversations using input tools such as positioning and
devices (e.g., mouse, tablet, and such), and using high-
graphics objects for output (e.g., line drawings, raster blocks
images, possibly intermixed with text) should be possible on one
more of these screens
Moreover, as long as the technological trend continues in
predicted path, one can postulate a workstation which could
by the mid 1980's multi-media conversations using voice and video
1
synchronized with text and graphics. At present, multi-
information management (i.e., acquisition, processing,
dissemination) is an active research area, but eventually it
become an engineering problem which, when solved, will add a
dimension to already feasible modes of interaction between user
workstation
1.2 Virtual Terminal
All virtual terminal protocols (VTPs) provide a vehicle
device-independent, bi-directional, 8-bit byte
communications between two VTP users. Most Vo so by invoking
device abstraction of real terminals, called a virtual terminal
As with a real device, a virtual terminal has a well-
architecture with its own character sets and functions. A VTP
the architectural features of the virtual terminal to provide
common language, an intermediate representation, between its
communicating entities. However a VTP user does not
directly with this virtual terminal. A function of a VTP is
local mapping between the site-specific order codes and the
terminal domain, thus allowing this adaptation to be transparent
the VTP users
The model of a personal workstation as a dedicated device
considerable resources affects the way we conceptualize
architecture of virtual terminals, both in breadth and depth
function. It also affects the way we view the virtual terminal vis
a-vis its local correspondents, the personal workstations, and
remote correspondents, the other virtual terminals
This document presents a radical view of virtual terminals
resource sharing devices. The classical concept of a
terminal as a two-way device with a limited architecture has
dismissed. Instead, we view a virtual terminal as an n-way
with multiple correspondents sharing access to its virtual "keyboard
and "display." In this model, a virtual terminal has two kinds
correspondents: adaptation units, and other virtual terminals.
adaptation units serve as interface agents between the
terminal and its users, providing the step transformation between
user-specific order codes and the virtual terminal
language. In turn, the other virtual terminals are
co-equals of the virtual terminal, interacting with it to
global control and data store synchrony. Resembling the
of a local copy of a distributed data base, the virtual
interacts with the other virtual terminals (the remote data
managers) and with the local adaptation units (the data
transformers) to provide read, write, and modify access to its
2
data store (the local copy of the distributed data base),
providing concurrency control to maintain a "single user view"
so desired
To communicate with its correspondents, a virtual terminal
two virtual languages. In the case where the correspondent is
virtual terminal, it uses the language of the virtual
protocol; in the case where the correspondent is an adaptation unit
it uses an interface language closer to the physical architecture
the end-user, but a virtual language nevertheless
In essence, the virtual terminal has become a device in its
right, free from a single physical realization and also
ownership. As a result, a single workstation not only may request
number of virtual terminals, but a number of workstations
share -- and interact with -- a particular virtual terminal
The functional breadth of virtual terminals has been
by the concept of virtual terminal classes. Each class is
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
operations (the virtual display); a general controlling element (
virtual controller); and an input selector (the virtual keys).
Finally, the functional depth of the virtual terminal has
extended by architectural features previously unavailable.
virtual terminal becomes a multi-user device with a non-
virtual display available for selective viewing. These concepts
discussed is some detail in the chapter that follows
1.3 The
An overview of the virtual terminal model and the management
communicating virtual terminals is presented. A detailed
description of the data structures and accompanying
functions has been completed. The operations and control
are less complete. Before the design is solidified, an
mimimal implementation will be made to validate the model
This document represents work in progress; current
interest in virtual terminal protocols has motivated us to
this as an example of mechanisms that a virtual terminal
support. The model provides a framework for supporting device
processing capabilities not yet commonly available. A
terminal protocol standardization effort may not want to include
the mechanisms that are described here, but it is our contention
one should not preclude these extensions for the future
3
1.4 Related
The concepts presented in this document are the offspring
previous work in the area of personal computing, and of
interfaces to (distributed) systems. The bibliography at the end
the document collects this material. In particular, we want
acknowledge the work done at the University of Rochester on
terminals,(6) work which has influenced to a large degree how
view user interfaces through a display
4
2.0 THE VTM
This section describes a virtual terminal management (VTM)
whose architecture not only derives from a quest for device
independent, terminal-oriented communications, but more
from a desire to provide effective human-machine interfaces
The VTM architecture is a multi-user structure which
several building blocks. The underlying foundation to this
is provided by the cooperating virtual terminals. Under the
model, these cooperating virtual terminals are viewed as
abstractions, all with a common architecture, exchanging
terminal protocol items to update each other's view of the world
Resting on this foundation lie the adaptation units. Associated
a single end-user, an adaptation unit provides the
transformation between user and virtual domains. In a sense
adaptation unit is also a virtual terminal, although one which
much closer to the architecture of the end-user. Finally, on top
this supporting structure are the end-users, the application
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
the model and its underlying concepts stems from our desire
provide productive user environments
HUMAN <--->
o Multiplexing the workstation physical display both in
and space
The workstation assigns to each user conversation a
terminal with a well-distinguished logical display.
the user control, the workstation maps these
displays on non-overlapping areas of the physical display
providing a dedicated workspace between user
correspondents. Limited only by the area of the display
many logical displays could be mapped at one time,
providing display updates when so required. Since the
of the display is a scarce resource, not all
displays need be mapped at the same time. Therefore,
workstation may roll-out and roll-in selected displays
the user control, thereby also multiplexing the
display in time
o Multiplexing the workstation input devices in time
5
The input devices always map to a single user
(i.e., a single logical terminal). However, the user
select a new logical terminal by some well-
interaction (e.g., depressing a function key, using
pointing device, and such), effectively switching
ownership of the input tools
o Concurrent multi-mode use of the workstation
The capabilities of the workstation limit the scope
character of the individual conversations. If
workstation supports rubout processing (i.e.,
operations on lines and characters), then the
terminals can be independent, scrolling "terminals,"
page-oriented, others line-oriented. If the architecture
the workstation supports graphics objects as
objects then so can the individual logical terminals. As
consequence, while some logical terminal displays may
dedicated to alphanumeric output, others may include
graphics and imaging data together with positioned text
o The sharing of a single logical terminal among
users
Several end-users may link to a single logical terminal
All linked parties are viewed by the shared "device" as
input sources and output sinks. As a consequence
device sharing need not be limited only to the sharing
device output. In general, each linked party may have
read and write access to the logical terminal, if it
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,
"device" display. This window provides the "peephole
through which the device display is viewed. The portion
the device display mapped on this window is not limited
its "present contents." Under the user control,
workstation may invoke the viewing of past activity on
logical terminal display when the device display is I/
file-extended. Since the window mechanism is an
part of the device architecture, it is available on
logical terminal displays. Furthermore, the viewing of
activity does not affect others sharing access to
device
6
o Discarding, suspending, and resuming the output of a
terminal always under user control
As part of the user interface, the workstation
simple "keys" through which the user controls the output
a logical terminal display. These workstation "keys"
not be physical keys, but could be other input tools
for this purpose (e.g., analog dials, hit-sensitive areas
the physical display, and such). In any event, through
auspices of the workstation, the user's control
translate into the proper commands to the "device
associated with the logical terminal
APPLICATION <---> ADAPTATION
o A logical view of real devices
For each real terminal architecture, one
representation: a logical device
o For a particular logical device, several
interaction paradigms
Some logical devices are intrinsically half-duplex (e.g.,
page-oriented logical device), some are full-duplex (e.g.,
communicating processes using a stream-oriented
device), and some may be either half or full-duplex (e.g.,
line-oriented logical device). Some full-duplex
devices can provide no echoing, remote echoing, or
echoing. Those that interface with applications
support command completion (e.g., command-line interpreters
can shift the locus of echoing as a function of a
break character set
o One application communicating with several logical devices
As part of an application's model of interaction,
application may "own" several logical devices. For example
an editor could use a line-oriented logical device to
top-level commands, and a page-oriented logical device
provide editing workspace
2.1 The VTM Model
The virtual terminal management model consists of two
components: the virtual terminal model, and the workstation
(see Figures 2.1, 2.2, and 2.3 respectively).
7
AU
|
AU0 | AU
| | |
_______________
| |
| VT2 |
| |
| |
_______________
| _______________
| | |----AU
|_______| VT0 |
|_______| |
| | |----AU
| _______________
|
________________
| |
| |
| VT1 |
| |
________________
| | |
AU0 | AU
|
AU
VT = VIRTUAL
AU = ADAPTATION
FIGURE 2.1 - THE VIRTUAL TERMINAL
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
The first component embodies the canonical device, while the
component includes the adaptation unit and its
environment. Each component will be described in turn below
2.2 The Virtual Terminal
The objective of virtual terminal protocols is to provide
users of the service with a common, logical view of terminals.
common user view is attained through a standard, protocol-
representation of a canonical terminal, the virtual terminal.
10
permits the exchanges between users of the protocol to be free
device-specific encodings
The design postulates an integrated virtual terminal model
extends the nature and scope of this canonical device in
important ways. The major aspects of the model, its connectivity
its organization, and its architecture are described below
2.2.1 Virtual Terminal
Most virtual terminal protocols only cater to two-way
in which a single virtual terminal terminates each end of
communication path
We define the virtual terminal as a n-way device where one
more of the correspondents to this device are local users of
service, and the remaining correspondents (if any) are peer
terminals. Each correspondent to the virtual terminal has its
bi-directional path to produce virtual input to, and receive
output from, the virtual terminal. This bi-directional path
the vehicle for a virtual terminal session between user and
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
terminal from its physical realization, a single real terminal
Indeed, a virtual terminal does not map necessarily to just one
device, but possibly to many real devices
The virtual terminal is viewed ultimately as a well-defined
structure which provides its correspondents with a non-
virtual terminal service. And these correspondents may have
only, write only, or read/write access rights to this data structure
2.2.2 Virtual Terminal
The virtual terminal is an abstraction; its organization,
building blocks which make up the virtual terminal, is the result
a feature extraction of the real terminal that it is tailored
support
We have conceptualized the virtual terminal as a meta-
(i.e., the terminal of terminals). The meta-terminal is composed
three well-distinguished building blocks: virtual keys, a
controller, and a virtual display
11
2.2.2.1 The Virtual Keys. The analog of the virtual keys
the physical keyboard of real terminals. However, while the keys
a physical terminal are controlled by a single manual process,
virtual keys can be activated by multiple, concurrent entities (
virtual terminal correspondents). Each correspondent of the
terminal, be it a user of the service or a peer virtual terminal,
its input stream to the meta-terminal terminated at the virtual keys
The virtual keys provide the control of access of input streams
the meta-terminal
2.2.2.2 The Virtual Controller. The virtual
provides virtual terminal session management. It manages
establishment and termination of a virtual terminal session with
correspondent; supports the possible negotiation and renegotiation
the session attributes; and enables the deactivation and
activation of the session. The virtual controller also
virtual terminal signalling control by managing the out-of-
signals addressed to the virtual terminal
2.2.2.3 The Virtual Display. The virtual display is
dynamic component in the meta-terminal organization. For each
of real device (e.g. stream, line, page, or graphics-
devices) there is a corresponding virtual terminal class.
organization of the virtual terminal data structure is class
specific. A virtual terminal models a particular terminal class
it is 'fitted' with the proper data structure manager or
display. This binding need not be static (e.g., a line-
specialist, and so forth), but could be result of decisions made
"run-time" by applying the principle of negotiated options
The virtual display manages the data structure associated
the meta-terminal and performs operations on the control and
elements of the structure. As a direct consequence of
operations on the meta-terminal data structure, the virtual
may generate display updates to one, some, or all of
correspondents. All virtual terminal output streams originate at
virtual display
Different virtual terminal classes are spawned by
"kinds" of virtual displays, and this is realized in one of two ways
For character-oriented virtual devices, it is possible to use
single, wide-scoped virtual display with a character-oriented
structure by constraining it to conform to the model of the
class (e.g., line-oriented devices must be constrained to line-
rules). For non character-oriented virtual devices (e.g.,
devices), an altogether different virtual display must be used
12
properties better suited for the new domain (e.g., a graphics
display based on a structured display file).
2.2.3 Virtual Terminal
The commands, and associated parameters, which are available
the users of the virtual terminal constitute the virtual
architecture. The commands available to a user -- to request
virtual controller to establish, abort, or close a session,
discard, suspend, or resume output -- remain invariant to the
terminal class. However, as one would expect, the user interface
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-
virtual display, and the concept of virtual display windows. Each
these concepts are a part of the meta-terminal architecture
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
standard, protocol-wide name which we call a communication variable
The communication variable is a part of the header of each command
the virtual terminal (i.e. protocol item). It permits
management of the virtual terminal command name space, and
provides the virtual keys with an easy mechanism to select
destination of the request. It must be noted that nothing in
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
alleviates the problems of device selection and command
allocation in the case of such extensions
2.2.3.2 Virtual Display with File Extension. The
display is the immediate manager of the meta-terminal data structure
When the virtual display is provided with an I/O file extension,
is possible to introduce the concept of a stable-store
structure, a data structure whose contents are stored in
store (e.g., disk). If the virtual display is provided with
file extension capability (a local option with no end-to-
significance), then the meta-terminal data structure inherits
spatial and temporal attributes (dimensions and time-to-live) of
associated file. Such a virtual display, coupled with the concept
virtual display windows below, provides the users of the service
a very powerful tool
13
2.2.3.3 Virtual Display Windows. To communicate with a
terminal, each real device uses an adaptation unit as its
entity (this adaptation unit is a part of the workstation model,
section 2.3). What is important to note is that the adaptation
provides the transition between the device-specific domain,
device workspace, and the virtual domain, the master workspace (
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
15
However a device need not be interested in the whole
workspace, only in a portion of it. As part of its
attributes, each adaptation unit has a window, a rectangular
in the virtual display, which delimits its area of interest in
master. This portion of the master domain will be referred as
instance workspace. Then, for each adaptation unit, there is
instance workspace whose spatial attributes (dimension and
within the master) are those of its window definition
All adaptation units communicate with the virtual
"relative" to their own instance workspace. As far as the
terminal is concerned, each instance workspace defines a "real
terminal, although in fact it is just an intermediate
of the real device. In essence, the instance workspace is
coordinate space where both virtual terminal and adaptation
rendezvous. (See section 2.3 for a discussion of how this
workspace is mapped onto the device workspace).
The window dimensions are the exclusive choice of the
unit that owns it. With these dimensions the adaptation
specifies to the virtual terminal how much of the master is to
viewed; data elements not contained within the boundaries of
window are clipped. Varying the dimension of the window results
corresponding changes on the amount of the master that is viewed
In contrast, the position of the window on the master might
be under direct control of the adaptation unit. To understand
dynamics of a window, we introduce the notion of a master cursor
an instance cursor. The master cursor is a read/write pointer,
is a part of the virtual display architecture. In turn, the
cursor is a pointer owned by the adaptation unit, which is a part
the state information maintained by the virtual display. Normally
both master and instance cursors are bound together so that motion
one cursor translates into an equivalent motion of the other.
long as the adaptation unit does not explicitly unbind its
cursor from the master cursor, the active region of the master (i.e.,
the position where the master cursor lies) is guaranteed to be
within the instance space, and thus viewable. This means
certain operations on the virtual display will implicitly
the window of an adaptation unit within the bounds of the
workspace to insure the tracking of the master cursor. (The
algorithm which enforces this tracking rule, called the
algorithm, has not been included here.) This window relocation
16
viewed at the real terminal as either vertical or
scrolling
However, an adaptation unit has the choice to bypass this
by detaching its instance cursor from the master, effectively
complete control of its cursor to view other portions of the
space. If the virtual display has an I/O file extension, then
adaptation unit can pan its window on the file-extended space
beyond the present contents of the master space. Therein lies
power of a stable-store data structure when coupled with the
of windowing
2.3 The Workstation
The workstation model is composed of one or more
units, and a workstation monitor, which we will call the executive
Each will be described in turn below. In addition, the
includes input and output handlers, and an underlying multi-
operating system of unspecified architecture
2.3.1 The Adaptation
An adaptation unit embodies an instance of a virtual terminal
and since the workstation model postulates possibly many
such instances per physical workstation, then potentially
adaptation units will be co-located at a workstation
The adaptation unit can be viewed as the workstation agent
provides the mapping between instance workspace and device workspace
To define this mapping, we introduce the notion of a viewport as
rectangular area of the physical screen allocated for the viewing
a virtual terminal instance. An adaptation unit has the task
mapping the totality of the instance workspace onto the viewport,
mapping which is a device-specific concern totally removed from
domain of discourse of the virtual terminal. Thus the position
the viewport determines the relocation of the selected data
elements on the viewing unit, and the viewport dimensions
(potential) scaling transformation
The adaptation unit also produces virtual input to the
terminal by translating the user input into virtual
commands. It implements the service side of the interface to
virtual terminal
17
2.3.2 The
This conceptual entity performs the task and resource
required to create and destroy virtual terminal instances, and to
these virtual terminal instances to the screen viewports
It must provide at least a minimal user command interface
that its tools may be accessed (one of them being the management
screen real estate).
Finally, the executive provides the mechanism for the end-
to switch viewport contexts through the use of some input
(e.g., function key, pointing or positioning device). Following
user interaction which indicates a change of context, the
makes the newly selected virtual terminal instance the
owner of the input devices
18
1. R. Bisbey II and D. Hollingworth. "A distributable, display
device-independent vector graphics system for the
command and control environment," Information
Institute, Marina del Rey, California, April 1978.
2. Alan Branden, et al. "Lisp Machine Project Report,"
Intelligence Laboratory, Massachusetts Institute of Technology
AIM 444, August 1977.
3. John Day. "TELNET Data Entry Terminal Option," ARPA
Working Group RFC 732, Network Information Center,
International, September 1977.
4. Douglas Gerhart and D. L. Parnas. WINDOW A formally
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
Single-User Machine," Proc 7th Symposium on Operating
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,"
2, ARPA Order No. 2302, SRI Project No. 6933, SRI International
Menlo Park, California, 1979.
8. Allen Newell, Scott Fahlman, Bob Sproull. "A Proposal
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
Transmission and Echoing Option," ARPA Network Working Group
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,"
Palo Alto Research Center publication SSL-80-3. Presented
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
Examples, editors, second edition, McGraw-Hill, 1979.
20
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
