-
Notifications
You must be signed in to change notification settings - Fork 4
/
rfc0094.txt
339 lines (226 loc) · 13.2 KB
/
rfc0094.txt
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
Network Working Group E. Harslem
Request for Comments: 94 J. Heafner
NIC: 5725 3 February 1971
Some Thoughts on Network Graphics
Purpose
This note states some of our initial reactions to NWG/RFC #86, whose
purpose was to provide a basis for discussion and development of
Network graphics.
The method of operation described in Note 86 was to interpret data
structures to produce graphic order codes for display. This method
has proven satisfactory in the past and we favor this approach. The
Note 86 proposal is directed toward a particular concept of operation
(i.e., minimal graphics terminal connected to computational
facilities at remote sites); our remarks embrace extended operations
that include smart programs at each end of the connection as well as
the minimal terminal.
The proposal in Note 86 should be broadened to include the
description of more complex entities and it should be raised to a
level of describing more general things. In this note, we first
criticize the limitations imposed by the details of Note 86; then
suggest some supplementary ingredients to extend its scope; and
lastly, we suggest an alternate approach that reduces Network
conversations (where possible) to symbol manipulation rather than
gross detail.
Comments on the Detailed Restrictions of Note 86
The detailed constraints enumerated in Note 86 restrict many
interesting features of the Rand display hardware that we consider
necessary (from a human factors standpoint) to some current
applications. They likewise restrict other nodes whose ARPA-
sponsored research is dependent upon the use of sophisticated
hardware. For example, the point, vector, and character capability
of Note 86 excludes line type mode, intensity control, and many other
attractive control operations; the maximum symbol sizes are too small
for our large character size; the origin of all of our symbols is
specified as the "centroid" of the symbol rather than the lower left
corner of a virtual rectangle encompassing the symbol; under mode
control for plotting purposes, the beam may not be advanced to the
next character position; a 7-bit ASCII is insufficient; etc. In
short, the five list items of Note 86 are not expressive enough; for
example, there is nothing to allow one to position and open a graphic
Harslem, et. al. [Page 1]
RFC 94 Some Thoughts on Network Graphics February 1971
compare "window". The problem was not treated of supplying
parameters identifying structure for match, etc. that are not actual
display commands.
Perhaps some necessary information gathering (i.e., the display
hardware descriptions and the characteristics of every node) is
preliminary to the generation of a detailed specification. It is
important that, without delay, a mechanism be defined for gathering
and collating this information in such a way that it doesn't deter
progress on Network graphics development.
Some General Extensions to the Note 86 Proposal
1. DISPLAY LANGUAGE CAPABILITIES SHOULD ENCOMPASS THE UNION OF
CURRENT AND ANTICIPATED NETWORK GRAPHICS HARDWARE. Our experience
in exploring interactive graphics communication techniques for use
by researchers and non-programmers indicates that this is not just
a "motherhood". The utility of such applications programs depends
highly upon incorporating sophisticated graphics hardware. In
absence of those features, some programs simply won't be used.
2. THE DATA STRUCTURE SHOULD ALLOW LOGICAL AS WELL AS PICTORIAL
REPRESENTATION OF THE USER'S PROBLEM. This close coupling of the
meaning of a picture with the actual picture is desirable from a
processing program's point of view, especially if a user is to
interact with the picture. We have found this an efficient way to
operate with the GRAIL Project and its derivatives here at Rand.
This technique is included in a recently proposed graphics
language generated by Bob Anderson (Rand) and Ben Wegbreit
(Harvard).
3. TRANSMIT DEFINITIONS OF GRAPHICS AND THEN INSTANCES OF THEIR USE.
The attempt here is to raise the level of "conversation" between
programs (where possible) and to reduce processing overhead. For
example, if one wishes to draw lots of resistors, why not
graphically define a resistor once and then transmit instances by
giving the definition name accompanied by attributes? A typical
form of an instance is shown below.
Item Name (position, size, intensity, scaling, labeling,
rotation, etc.)
There are many examples of this approach such as the recent work
by William Newman (Utah) and many earlier studies at MIT.
4. PARTITION THE DISPLAY STRUCTURE FOR 1) STATIC VS. DYNAMIC
INFORMATION, AND 2) CONTEXT. As opposed to refreshing an entire
picture whose domain is the entire screen, we have found it useful
Harslem, et. al. [Page 2]
RFC 94 Some Thoughts on Network Graphics February 1971
to give the processing routine (that wishes to draw a picture)
knowledge of only of a named rectangular portion of the CRT and an
accompanying display structure. With our particular hardware we
can then update only the dynamic part of a picture rather than
regenerating the entire display structure. Just as important, we
can logically assign areas of the CRT to different concurrent
processing routines. Coupled with the logical/pictorial
representation noted in 2) above, this is a powerful technique.
Named partitions also naturally accommodate those applications
requiring multiple CRTs.
5. THE INTERPRETER COULD BE CONTEXT-DRIVEN THUS NOT RESTRICTING ITS
OUTPUT TO A SINGLE SET OF CRT ORDER CODES. By providing cataloged
descriptions such as the "forms" discussed in Note #83, the
interpreter could reconfigure data destined for files, etc., as
well as a display. The gain here in terms of adapting to a users'
Network needs is large; the price paid in terms of implementing
this increment of the interpreter is probably small.
An Alternate Proposal
Note 86 mentions the case of a terminal at a node with a minimal HOST
connected to a remote computationally-oriented node. The data
standard, which Note 86 suggests transmitting over the Network is
rather gross detail. Also, the standard language is rather
inexpressive -- encompassing only a few simple notions.
An alternative approach is to consider the situation of communication
between non-minimal nodes (nodes with substantial memory and
computing power). Here the Network standard data should be a high-
level macro form representing the instances of gross detail with the
power to deal with sophisticated graphics devices. That is, the
standard language would be rich enough to express all the special
features of Network display devices.
This suggestion presents two problems. First, how can a terminal
handle commands from a remote program of which its hardware is
incapable? The answer is that the remote program to which it is
connected is too sophisticated for the terminal -- the connection is
invalid. A terminal should NORMALLY only connect to a program that
addresses no more than its hardware capabilities. This concept
allows a standard under which a simple terminal and a simple program
can communicate (exactly the proposal of Note 86), yet a
sophisticated terminal can talk to a sophisticated program in a
high-level language, or it can talk to a simple program, all within
the same Network standard.
Harslem, et. al. [Page 3]
RFC 94 Some Thoughts on Network Graphics February 1971
The second problem is that a minimal host might not have sufficient
facilities to translate from a powerful Network standard language
into the simple, detailed order codes of its terminals.
When required, the needs of a minimal site would be handled by
another Network node providing data reconfiguration services, AN
ESSENTIAL PART OF THIS PROPOSAL. The reconfiguration would be done
on the basis of "forms" specifying translation form the Network
standard to the specific non-standard data format required by the
minimal node (i.e., tailored specifically to its hardware). Whether
it would be graphic order codes or some intermediate form would
depend on the processing power and requirements of the minimal node.
Fig. 1 shows a schematic diagram of the key elements of such a
reconfiguration facility. Fig. 2 shows the use of that facility by a
local display handler and its use as an intermediary by two remote
nodes requiring different degrees of external data reconfiguration.
Harslem, et. al. [Page 4]
RFC 94 Some Thoughts on Network Graphics February 1971
Network
| ^
| |
| |
v |
+--------------+
| A Network | Local
| Process |---> Files, Programs,
| Invoking the |<--- CRTs, etc.
| Interpreter |
+--------------+
| ^
| |
| |
v |
+--------------+ +--------------+ (A user can access
| | | User's | the logical
|-->| Interpreter | | Semantic | representation of
| | | | Routines | his problem.)
| +--------------+ +--------------+
| | ^ | ^
| | | | |
| | | | |
| v | v |
| +-------------------+
| | |
| | Primitive |
| | Data Structure |
| | Operators |
| | |
| +-------------------+
| | ^
| | |
+--------------+ | |
| Data Base of | v |
| "Forms" for | +------------------+
| Reconfigu- | | Data Structure |
| ration | | Base: |
+--------------+ | 1 - Pictorial |
| 2 - Logical |
+------------------+
Fig. 1. Data Reconfiguration Service
Harslem, et. al. [Page 5]
RFC 94 Some Thoughts on Network Graphics February 1971
Host Providing Host Providing
Computational Facility Reconfiguration Service
+--------------------+ STANDARD +-----------------------------+
| | FORMAT | +----------+ +-----------+ |
| |------------|--| Inter- |-| Display | |
| | (of Macro | /| preter | | Handler | |
| | Form Data) |//+----------+ +-----------+ |
+--------------------+ //--------------------|-------+
// |
/( +-----------+
/ \ | Terminal |
/ \ +-----------+
/ \
/ \
/ \
NON-STD. / \ NON-STD.
(Terminal Order Codes) / \ (Detailed Data)
/ \
/ \
/ \
/ \
/ \
/ \
| |
+-------|-------+ +-------|-------+
| | | | +-----------+ |
Minimum | | | | | Display | | Minimum
Host | | | | | Handler | | Host
| | | | +-----------+ |
+-------|-------+ +-------|-------+
| |
+-----------+ +-----------+
| Terminal | | Terminal |
+-----------+ +-----------+
Fig. 2. Use of Data Reconfiguration Service
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Sergio Kleiman]
Harslem, et. al. [Page 6]