RFC 782
Virtual Terminal management model
A Virtual Terminal Management Model 🎀
RFC 782 ✨ Prepared for the Defense Communications Agency, WWMCCS ADP Directorate, Command and Control Technical Center, 11440 Isaac Newton Square, Reston, Virginia 22090. 💖
By Jose Nabielsky and Anita P. Skelton 🫶, of The MITRE Corporation, MITRE C(3) Division, Washington C(3) Operations, 1820 Dolley Madison Boulevard.
Okay bestie, the title block is basically the cast list 🎬. This is an RFC, so the paperwork is in here too: who wrote it, who it was prepared for, and the number. 🦋
Table of Contents 💅
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 19List of Illustrations 🌸
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 141.0 INTRODUCTION 🧚
Okay so the big picture 🖼️: micro-electronics got really good, and we now have inexpensive but powerful microprocessors. Honestly this is giving the 1960s again ⏳, when we went from batch processing to time-sharing. The trend points toward decentralized setups where the processing power moves closer to the user, in the form of smart personal workstations. The virtual terminal model in this document is built for that personal computing future. ✨
1.1 The Workstation Environment 💻
A personal workstation is a computing engine made of hardware and software that serves a single user. 🫶 The workstation can also invoke the resources of other, physically separate components, so your personal environment stretches way past the one box on your desk. 🌈
In this personal setup, processing resources that used to be shared among many users now belong to just one person 👑. A big chunk of those resources goes into making the human-machine interface feel effortless. 💅 So input and output methods that weren't realistic under time-sharing now count as part of a real conversation between user and workstation. Because there are spare processing cycles right next to the user, the workstation can support interactive devices and dialogue modes that couldn't be afforded before. 🔥
The workstation can also give the user the tools to hold several conversations at once with user-agents located elsewhere in the global architecture 🌍. One of those tools is splitting the physical display into multiple logical displays, where one or more of those logical displays gives the user a dedicated workspace with an agent. 🦋
These conversations don't have to be plain alphanumeric text 📝. Input with positioning and pointing devices (e.g., mouse, tablet, and such) should be possible on one or more of these screens, and so should output using high-resolution graphics objects (e.g., line drawings, raster blocks and images, possibly mixed with text). 🎨
Now here's the spicy prediction 🔮: if the technology trend keeps going the way it's going, a workstation could support multi-media conversations using voice and video by the mid 1980's, synchronized with text and graphics. 🎥
Right now, multi-media information management (i.e., acquisition, processing, and dissemination) is an active research area. Eventually it will become an engineering problem, and once it's solved, it adds a whole new dimension to the interaction modes that already work between user and workstation. 🌟
1.2 Virtual Terminal Management 🖥️
All virtual terminal protocols (VTPs) give you a way to do device-independent, bi-directional, 8-bit byte oriented communication between two VTP users. 💜 Most VTPs do this by invoking a device abstraction of real terminals, called a virtual terminal.
Just like a real device, a virtual terminal has a well-defined architecture, with its own character sets and functions ✨. A VTP uses those architectural features to provide a common language, an intermediate representation, between its two communicating entities. 🗣️ The VTP user never talks to the virtual terminal directly though 🙈. One of the VTP's jobs is the local mapping between site-specific order codes and the virtual terminal domain, so the adaptation stays invisible to the VTP users. 🫧
Thinking of a personal workstation as a dedicated device with lots of resources changes how we picture virtual terminal architecture 🧠. It changes both how much the thing can do and how deep its functions go. It also changes how we see the virtual terminal in relation to its local correspondents (the personal workstations) and its remote correspondents (the other virtual terminals). 💞
This document has a radical take: virtual terminals as resource sharing devices. 💅 The old idea of a virtual terminal as a two-way device with a limited architecture? Dismissed, periodt 💀. Instead, a virtual terminal is an n-way device with multiple correspondents sharing access to its virtual "keyboard" and "display." 🎹 So a virtual terminal has two kinds of correspondents: adaptation units, and other virtual terminals 🧩.
Adaptation units are the interface agents between the virtual terminal and its users. They do the step transformation between user-specific order codes and the virtual terminal interface language. 🔁 The other virtual terminals are cooperating co-equals, and they work with it to keep global control and data store synchrony. 🤝 Think of the virtual terminal like the administrator of a local copy of a distributed database 🗄️. It talks to the other virtual terminals (the remote database managers) and to its local adaptation units (the database transformers) to give read, write, and modify access to its local data store (the local copy of the distributed database). Meanwhile it provides concurrency control to keep a "single user view" when that's wanted. 👀
To talk to its correspondents, a virtual terminal uses two virtual languages 🗨️. When the correspondent is another virtual terminal, it uses the language of the virtual terminal protocol. When the correspondent is an adaptation unit, it uses an interface language that's closer to the physical architecture of the end user, though it's still a virtual language. 🧃
So basically the virtual terminal becomes its own device 🪞, free from any single physical realization, and also free from dedicated ownership. 🌷 That means one workstation can request any number of virtual terminals, and a bunch of workstations can share, and interact with, one particular virtual terminal. 🫶
The functional breadth of virtual terminals got a glow-up too, through virtual terminal classes 🎀. Each class abstracts a particular device architecture. There are stream, line, logical page, physical page, and graphics virtual terminals. Each one is 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). 🧚
And the functional depth of the virtual terminal got extended with architectural features that weren't available before ⭐. The virtual terminal is now a multi-user device with a non-volatile virtual display that you can view selectively 🌈. These concepts get more detail in the chapter that follows. 📖
1.3 The Scope 🔭
This document gives an overview of the virtual terminal model and of how communicating virtual terminals are managed. 📋 A detailed design description of the data structures and the accompanying addressing functions is done. The operations and control mechanisms are less complete 🚧. Before the design gets locked in, an initial minimal implementation will be built to validate the model. ✅
This is a work in progress 🛠️. Current international interest in virtual terminal protocols is what pushed the authors to submit this as an example of mechanisms a virtual terminal should support. 🌍 The model provides a framework for supporting device and processing capabilities that aren't commonly available yet 🔮. A virtual terminal protocol standardization effort may not want every mechanism described here, but the authors' take is that we shouldn't rule out these extensions for the future. 🫶
1.4 Related Work 📚
The ideas here are the offspring of earlier work in personal computing, and in user interfaces to (distributed) systems 🧬. The bibliography at the end of the document collects that material. 📑 The authors specifically want to acknowledge the work done at the University of Rochester on virtual terminals (6) 🙌, which has shaped a lot of how they think about user interfaces through a display. 🖥️✨
2.0 THE VTM MODEL 👑
This section describes a virtual terminal management (VTM) model 🎯. Its architecture doesn't just come from a quest for device-independent, terminal-oriented communications. It comes even more from a desire for effective human-machine interfaces 💖.
The VTM architecture is a multi-user structure that spans several building blocks 🧱. The foundation under this structure is the cooperating virtual terminals 🫧. Under the VTM
So in this model, these cooperating virtual terminals are basically device abstractions, all with a common architecture. They swap virtual terminal protocol items to keep each other updated on the state of the world 🌍✨. Resting on this foundation are the adaptation units. Each single end-user has an adaptation unit that does the step transformation between the user domain and the virtual domain. It's kinda like an adaptation unit is also a virtual terminal, just one that's way closer to the architecture of the end-user 🧠💖. And on top of all this structure are the end-users, the application and human processes, all working toward one common goal 🎀👑.
Before we get into the VTM model components, let's look at the capabilities the VTM model gives its end-users, whether they're human or application 💅. The whole motivation for the model and its underlying concepts comes from wanting to create productive user environments, so this list matters 🦋.
HUMAN <---> WORKSTATION
- Multiplexing the workstation physical display both in time and space. The workstation gives each user conversation its own logical terminal with a well-distinguished logical display 🌸. Under user control, the workstation maps these logical displays onto non-overlapping areas of the physical display, which gives the user and their correspondents a dedicated workspace. The only real limit is the area of the display, so many logical displays could be mapped at one time, each one updating when needed. The display area is a scarce resource, though, so not all logical displays need to be mapped at the same time. That means the workstation may roll-out and roll-in selected displays under user control, which also multiplexes the physical display in time ⏰✨.
- Multiplexing the workstation input devices in time. The input devices always map to a single user conversation (a single logical terminal) 🎯. The user can still select a new logical terminal through some well-defined interaction, like pressing a function key or using a pointing device, and stuff like that. That effectively switches who owns the input tools 🔄.
- Concurrent multi-mode use of the workstation. The workstation's capabilities limit the scope and character of each individual conversation 🧁. If the workstation supports rubout processing (erase operations on lines and characters), the logical terminals can be independent, scrolling "terminals," some page-oriented and others line-oriented 📜. If the workstation architecture supports graphics objects as primitive objects, then so can the individual logical terminals 🎨. So some logical terminal displays may be dedicated to alphanumeric output, while others include raster graphics and imaging data together with positioned text 🌈.
- The sharing of a single logical terminal among several users. Several end-users can link to a single logical terminal 🫶. The shared "device" sees every linked party as both an input source and an output sink 💜. So device sharing doesn't have to be limited to sharing device output. Generally, each linked party can have full read and write access to the logical terminal, if they want it 🔥.
- Selective viewing on a logical terminal display. From the user's point of view, a logical terminal display is a user-specified window onto a potentially larger structure, the "device" display 🪟. This window is the "peephole" through which the device display gets viewed. The portion of the device display mapped onto the window isn't limited to its "present contents" 🕰️. Under user control, the workstation can invoke 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's available on all logical terminal displays. Plus, viewing past activity doesn't affect anyone else sharing access to the device 🙈.
- Discarding, suspending, and resuming the output of a logical terminal, always under user control. The workstation gives the user simple "keys" to control the output on a logical terminal display 🎹. These workstation "keys" don't have to be physical keys. They could be other input tools used for the same purpose, like analog dials or hit-sensitive areas on the physical display, and such 🎛️. Either way, through the workstation, the user's control requests get translated into the right commands to the "device" tied to that logical terminal 🧚.
APPLICATION <---> ADAPTATION UNIT
- A logical view of real devices. For each real terminal architecture, there's one canonical representation: a logical device 🍓.
- For a particular logical device, several possible interaction paradigms. Some logical devices are intrinsically half-duplex (for example, a page-oriented logical device), some are full-duplex (for example, communicating processes using a stream-oriented logical device), and some may be either half or full-duplex (for example, a line-oriented logical device) 🦄. Some full-duplex logical devices can provide no echoing, remote echoing, or local echoing 🔁. Those that interface with applications supporting command completion (like command-line interpreters) can shift the locus of echoing based on a dynamic break character set 🌟.
- 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 its editing workspace ✍️💕.
2.1 The VTM Model Components ✨
The virtual terminal management model is made up of two major components: the virtual terminal model and the workstation model. See Figures 2.1, 2.2, and 2.3 respectively 🗺️.
AU1
|
AU0 | AU2
| | |
_______________
| |
| VT2 |
| |
| |
_______________
| _______________
| | |----AU0
|_______| VT0 |
|_______| |
| | |----AU1
| _______________
|
________________
| |
| |
| VT1 |
| |
________________
| | |
AU0 | AU2
|
AU1
VT = VIRTUAL TERMINAL
AU = ADAPTATION UNIT
FIGURE 2.1 - THE VIRTUAL TERMINAL MODEL ___ ___ ___ ___
|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) +--------------------+
| |
o-|-------------------|
| EXECUTIVE |
|--------------------|
Screen +-------+ o-|--------------------| +-----+
+---------+ /|OUTPUT | | ADAPTATION UNIT 0 |<---->| VT0 |
|EXECUTIVE| / | |<---|--------------------| +-----+
|---------| / |HANDLER| o-|--------------------| +-----+
| AU0 | / |-------| | ADAPTATION UNIT 1 |<---->| VT1 |
|---------| / | INPUT | |--------------------| +-----+
| AU1 |/ | | o-|--------------------|
|---------| |HANDLER| | . |
| | | /--|o | . |
~ ~ +-------+ ~ . ~
~ ~ / ~ ~
|---------| / o-|--------------------| +-----+
| AUK | / | ADAPTATION UNIT K |<---->| VTK |
+---------+ / +--------------------+ +-----+
/ | |
+---------+ / +--------------------+
|Keyboard | /
+---------+ /
|[] [] [] | /
|[] [] [] |/
+---------+
FIGURE 2.3 - THE WORKSTATION MODELThe first component is the canonical device, and the second component includes the adaptation unit and its associated environment 🧩. We'll go through each one in turn below 💜.
2.2 The Virtual Terminal Model 🌸
The main goal of virtual terminal protocols is to give the users of the service a common, logical view of terminals 🎀. That common user view comes from a standard, protocol-wide representation of a canonical terminal, which is the virtual terminal ✨. This means the exchanges between users of the protocol can be free of device-specific encodings 🫧.
The design is built on an integrated virtual terminal model. It 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. okay bestie, this is the good part 🧚✨
2.2.1 Virtual Terminal Connectivity ✨
most virtual terminal protocols only cater to two-way dialogues 🥱 where one virtual terminal sits at each end of the communication path. literally so basic.
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 is 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. main character energy 👑
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. it's giving curated 🍓
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. iconic trio 🌈
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. gatekeeper vibes 🚪💜
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. the manager of the whole vibe 📋✨
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. so flexible, no cap 🦋
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. the source of all the tea ☕🔥
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 properties better suited for the new domain (e.g., a graphics virtual display based on a structured display file). two paths, both iconic 💖
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. the rules stay the same, the screen changes 🙈
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. the three that everyone actually notices 👀
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. naming hierarchy slay 🧚♀️💅
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. the storage glow-up is real 🥹💜
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). the diagram below is lowkey the whole vibe 🖼️
| | |
| 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 DOMAINShowever 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. zoom in, pick your frame 🔍🦋
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
This is the rendezvous spot 📍 (see section 2.3 for how this instance workspace gets mapped onto the device workspace).
The window dimensions are the exclusive choice of the adaptation unit that owns it. Nobody else gets a vote 💅 With those dimensions, the adaptation unit tells the virtual terminal how much of the master is to be viewed. Data elements that aren't inside the window's boundaries get clipped ✂️ So if you change the window's dimensions, you change how much of the master you can see. Simple, but iconic.
Now the position of the window is a different story 🙈 The adaptation unit might not have direct control over it. To understand how a window moves, we need two new ideas: the master cursor and the instance cursor. The master cursor is a read/write pointer that lives in the virtual display architecture. The instance cursor is a pointer owned by the adaptation unit, and it's part of the state information the virtual display keeps. Normally, the two cursors are bound together, so when one moves, the other moves by the same amount 🦋
As long as the adaptation unit doesn't explicitly unbind its instance cursor from the master cursor, the active region of the master (aka wherever the master cursor is) is guaranteed to stay inside the instance space, which means it's always viewable 👀 This means some operations on the virtual display will quietly relocate an adaptation unit's window, staying within the bounds of the master workspace, just to keep tracking the master cursor. (The actual algorithm that enforces this tracking rule, called the viewing algorithm, is not included here.) At the real terminal, this window relocation just looks like vertical or horizontal scrolling 🌈
Plot twist: an adaptation unit can bypass this rule by detaching its instance cursor from the master. Then it gets complete control of its cursor and can wander off to view other parts of the master space 🏃♀️
If the virtual display has an I/O file extension, the adaptation unit can pan its window across the file-extended space, way past the current contents of the master space. This is where the power lives 💜 It's a stable-store data structure combined with the concept of windowing, and honestly that combo is so good.
2.3. The Workstation Model
Okay, the workstation model is made of one or more adaptation units, plus a workstation monitor, which we're going to call the executive 👑 We'll go through each one below. The model also includes input and output handlers, and an underlying multi-tasking operating system, whose architecture is unspecified 🧚
2.3.1 The Adaptation Unit
An adaptation unit is an instance of a virtual terminal 💖 The workstation model allows for possibly many of these instances per physical workstation, so potentially many adaptation units will be co-located at one workstation. Lots of besties in one place 🫶
The adaptation unit can be seen as the workstation agent that provides the mapping between instance workspace and device workspace. To describe this mapping, we introduce the viewport, which is a rectangular area of the physical screen allocated for viewing a virtual terminal instance 🖼️ The adaptation unit's job is to map the totality of the instance workspace onto the viewport. This mapping is a device-specific concern that's completely removed from the domain of discourse of the virtual terminal, so the virtual terminal doesn't have to care about it 💅 So the viewport's position determines where the selected data structure elements get relocated on the viewing unit, and the viewport's dimensions act as a (potential) scaling transformation 📐
The adaptation unit also produces virtual input for the virtual terminal by translating user input into virtual terminal commands ⌨️ It implements the service side of the interface to the virtual terminal. Main character energy, no cap ✨
2.3.2 The Executive
This conceptual entity handles the task and resource management needed to create and destroy virtual terminal instances, and to map those instances onto the screen viewports 🗂️
The executive must provide at least a minimal user command interface, so its tools can be accessed. One of those tools is managing screen real estate 🏡
Finally, the executive provides the mechanism that lets the end-user switch viewport contexts, using some input device like a function key or a pointing or positioning device 🎀 After a user interaction that signals a change of context, the executive makes the newly selected virtual terminal instance the dedicated owner of the input devices. So the focus literally moves to whoever you picked 👑
REFERENCES 📚
- 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.
- Alan Branden, et al. "Lisp Machine Project Report," Artificial Intelligence Laboratory, Massachusetts Institute of Technology, AIM 444, August 1977.
- John Day. "TELNET Data Entry Terminal Option," ARPA Network Working Group RFC 732, Network Information Center, SRI International, September 1977.
- Douglas Gerhart and D. L. Parnas. WINDOW A formally specified graphics based text editor, Computer Science Department, Carnegie-Mellon University, June 1973.
- 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.
- Keith Lantz. Uniform Interfaces for Distributed Systems, Ph.D. thesis, University of Rochester, Rochester, N.Y., May 1980.
- 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.
- Allen Newell, Scott Fahlman, Bob Sproull. "A Proposal for Personal Scientific Computing," Department of Computer Science, Carnegie-Mellon University, July 1979 (DRAFT).
- "PERQ," Three Rivers Computer Corp., 160 N. Craig St., Pittsburgh, Pa. 15213.
- 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.
- 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.
- R. F. Sproull and E. L. Thomas. A network graphics protocol, Computer Graphics 8(3), Fall 1974.
- 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.
That's the whole RFC, bestie! 🌈💖✨
📦 where this page comes from
- ietf: rfc782 1981-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms