1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
|
<pre> A Virtual Terminal Management Model
<a href="./rfc782">RFC 782</a>
prepared for
Defense Communications Agency
WWMCCS ADP Directorate
Command and Control Technical Center
11440 Isaac Newton Square
Reston, Virginia 22090
<span class="h1">by</span>
Jose Nabielsky
Anita P. Skelton
The MITRE Corporation
MITRE C(3) Division
Washington C(3) Operations
1820 Dolley Madison Boulevard</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'> TABLE OF CONTENTS
Page
LIST OF ILLUSTRATIONS vi
<span class="h3"><a class="selflink" id="section-1.0" href="#section-1.0">1.0</a> INTRODUCTION </span> 1
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a> The Workstation Environment </span> 1
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a> Virtual Terminal Management </span> 2
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a> The Scope </span> 3
<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a> Related Work </span> 4
<span class="h3"><a class="selflink" id="section-2.0" href="#section-2.0">2.0</a> THE VTM MODEL </span> 5
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a> The VTM Model Components </span> 7
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a> The Virtual Terminal Model </span> 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
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a> The Workstation Model </span> 17
2.3.1 The Adaptation Unit 17
2.3.2 The Executive 18
REFERENCES 19
iii</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'> 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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span class="h3"><a class="selflink" id="section-1.0" href="#section-1.0">1.0</a> INTRODUCTION</span>
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.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a> The Workstation Environment</span>
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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>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.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a> Virtual Terminal Management</span>
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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>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.
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a> The Scope</span>
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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a> Related Work</span>
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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span class="h3"><a class="selflink" id="section-2.0" href="#section-2.0">2.0</a> THE VTM MODEL</span>
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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'> 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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'> 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.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a> The VTM Model Components</span>
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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'> 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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'> ___ ___ ___ ___
|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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'> +--------------------+
| |
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.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a> The Virtual Terminal Model</span>
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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'> 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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'> 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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'> | | |
| 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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>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 <a href="#section-2.3">section 2.3</a> 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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>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.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a> The Workstation Model</span>
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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'> 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</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'> REFERENCES
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. R. Bisbey II and D. Hollingworth. </span> "A distributable, display-
device-independent vector graphics system for the military
command and control environment," Information Sciences
Institute, Marina del Rey, California, April 1978.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Alan Branden, et al. </span>"Lisp Machine Project Report," Artificial
Intelligence Laboratory, Massachusetts Institute of Technology,
AIM 444, August 1977.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. John Day. </span>"TELNET Data Entry Terminal Option," ARPA Network
Working Group RFC 732, Network Information Center, SRI
International, September 1977.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Douglas Gerhart and D. L. Parnas. </span>WINDOW A formally specified
graphics based text editor, Computer Science Department,
Carnegie-Mellon University, June 1973.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. B. W. Lampson and R. F. Sproull, "An Open Operating System for a</span>
<span class="h2"> Single-User Machine," Proc 7th Symposium on Operating Systems</span>
Principles 9-17, ACM, December 1979.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Keith Lantz. </span>Uniform Interfaces for Distributed Systems, Ph.D.
thesis, University of Rochester, Rochester, N.Y., May 1980.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Mathis, J.E., et al, "Terminal Interface Unit Notebook," </span>Volume
2, ARPA Order No. 2302, SRI Project No. 6933, SRI International,
Menlo Park, California, 1979.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Allen Newell, Scott </span>Fahlman, Bob Sproull. "A Proposal for
Personal Scientific Computing," Department of Computer Science,
Carnegie-Mellon University, July 1979 (DRAFT).
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. "PERQ," </span>Three Rivers Computer Corp., 160 N. Craig St.,
Pittsburgh, Pa. 15213.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Jon </span>Postel and Dave Crocker. "TELNET Remote Controlled
Transmission and Echoing Option," ARPA Network Working Group <a href="./rfc726">RFC</a>
<a href="./rfc726">726</a>, Network Information Center, SRI International, March 1977.
19</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. John F. Shoch and Jon A. Hupp. </span>"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.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. R. F. Sproull and E. L. Thomas. </span>A network graphics protocol,
Computer Graphics 8(3), Fall 1974.
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. C. P. Thacker, E. M. McCreight, B. W. Lampson, </span>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
</pre>
|
