rfc178.txt

RFC技术文档 从0000－05

Network Working Group                                      Ira W. Cotton
Request for Comments: 178                                          MITRE
NIC: 7118                                                  June 27, 1971


                   NETWORK GRAPHIC ATTENTION HANDLING


1.0 INTRODUCTION

   Discussions of network graphic protocols have thus far primarily
   dealt with protocols for the description of graphic data to be
   displayed.  RFC 86 proposed a Network Standard Graphic Data Stream
   (NGDS) which would serve to convey graphic images expressed in the
   Network Standard Display List (NGDL).  RFC 94 expanded on this
   proposal, and pointed out some shortcomings of the original scheme.
   RFC 125 also replied to RFC 86 with comments and extensions, but also
   recognized that a protocol for graphic display alone is insufficient
   to support an interactive graphic system.

1.1 TOPICS COVERED

   The present paper addresses itself to this requirement.  The process
   of attention handling is briefly described, various graphic
   configurations are discussed, input devices are surveyed to identify
   the types of data which they produce, and an attention protocol is
   suggested.

1.2 VIEWPOINT

   It should be made clear at the onset that the discussion which follow
   will be from the viewpoint of a graphics user or a graphic
   application program serving one or more users.  Our concern is with
   third-level protocols only.  We assume the network is capable of
   delivering arbitrary bit streams from terminal to graphic application
   program, but don't care how this is accomplished.

2.0 ATTENTION-HANDLING

   In order to demonstrate the need for an attention protocol, we must
   first define what is meant by "attention" and "attention-handling."
   We therefore begin by borrowing the definitions given in a recent
   survey of this area(1).








Cotton                                                          [Page 1]

RFC 178            NETWORK GRAPHIC ATTENTION HANDLING          June 1971


2.1 DEFINITION

   Graphic attention handling refers to the processes and techniques
   whereby human inputs to a computer graphic system are serviced.  An
   attention event, or simply "attention," is a stimulus to the graphic
   system, such as that resulting from a keystroke or light pen usage,
   which presents information to the system.  Servicing includes
   accepting or detecting the hardware input, processing it to determine
   its intended meaning, and either passing this information to a user
   routine or taking some _immediate_ action related to the display
   and/or its underlying data structure, or both.  The emphasis is on
   "immediate."  Attention-handling is not intended to include any
   detailed, application-oriented processing which the attention
   information may indicate is to be performed.  Thus, attention
   handling may be considered separately from any particular
   application.

2.2 INDEPENDENT FROM DISPLAY CONSIDERATIONS

   Not only may attention handling be considered separately from any
   application, but attention generating hardware may be considered
   separately from display hardware.  Oftentimes, it is only
   coincidental that they come in the same package.  Indeed, in some
   configurations an input be processed locally (by the terminal) to
   provide the appropriate response.  For example, a keystroke may or
   may not cause a character to be displayed on a terminal, and the
   logic causing the display may or may not be local (within the
   terminal).  The keystroke might be immediately displayed locally, as
   in the case of an alphanumeric display terminal which buffers
   keystrokes and transmits messages of many characters or it might be
   transmitted to the host computer and "echoed" back for display as in
   teletype-like terminals.

   The question is not limited to such simple input devices as
   keyboards.  So-called "intelligent terminals" with integrated
   programmable logic or even complete small computers can process more
   sophisticated attentions locally, and even alter a local distillate
   of the central (host) data structure without central knowledge.  This
   raises the problem of insuring that the display and the graphic
   application program do not get "out of sync," and requires a more
   expressive protocol from terminal to host processor.










Cotton                                                          [Page 2]

RFC 178            NETWORK GRAPHIC ATTENTION HANDLING          June 1971


3.0 SYSTEM CONFIGURATIONS

   We now turn to a consideration of the evolution of system
   configurations for computer graphics.  Our intent is to demonstrate
   that just as display generation has evolved from the output of device
   dependent codes to a generalized protocol, so too should attention
   generation evolve.

3.1 STAND-ALONE CONFIGURATION

   Figure 1 illustrates the stand-alone graphic configuration which was
   the first and is still the most common.  As we have stressed, input
   and output are entirely independent, and are shown as separate
   devices.  In this configuration, display code generation and
   interrupt processing are both done within the graphic application
   program in the host processor.  The graphic application is very
   device-dependent.

3.2 STAND-ALONE CONFIGURATION WITH STANDARDIZED FORMATS

   The significant conceptual change occurs when the input and output
   processors are removed from the graphic application program.  The
   graphic application program then generates output and accepts input
   in a generalized form, as illustrated in Figure 2.  The important
   fact to note is that in order to accommodate additional (different)
   input and/or output devices, only these input/output processing
   routines must be replaced or altered.  Graphic application programs
   may be designed without regard to which particular processing routine
   will be used.  So far as the application program is concerned,
   device-independence has been achieved.





















Cotton                                                          [Page 3]

RFC 178            NETWORK GRAPHIC ATTENTION HANDLING          June 1971


Figure 1 Stand-Alone Graphic Configuration

   +----------------------------+
   |                            |                _______
   | +---------+-----------+    |               /       \
   | |         |OUTPUT     |    |              /         \
   | |     /-->|PROCESSOR  |----|------------>|           |
   | |    /    +-----------+    |              \         /
   | |    |                |    |               \_______/
   | |    |                |    |             OUTPUT DEVICE
   | |    |    +-----------+    |              ______
   | |    \    |INPUT      |    |             |      \
   | |     \---|PROCESSOR  |<-- |-------------|_______\
   | +---------+-----------+    |
   |     Graphic Application    |             INPUT DEVICE
   |         Program            |
   +----------------------------+
   /SERVING\ HOST
   \USING  /


Figure 2 Stand-Alone Configuration with Standardized Input and Output
   Formats

+-------------------------------------+                        ______
|                                     |                 /---->/      \
|                      +-----------+  |DEVICE-DEPENDENT/  ___/___     \
|                    +-----------+ |--|---------------/  /       \    |
|        STANDARD    | OUTPUT    | |  |DISPLAY LIST     /         \   /
| +-----+DISPLAY LIST|PROCESSOR  |-+  |                 |         |__/
| |  ---|----------->|           |----|---------------->\         /
| |  |  |            +-----------+    |                  \_______/
| |  |  |                             |                 OUTPUT DEVICE(S)
| |  |  |                             |
| |  |  |              +-----------+  |DEVICE-DEPENDENT       ______
| |  |  |  STANDARD  +-----------+ |<-|----------------------|      \
| |  |--|<-----------|INPUT      | |  |INPUT DATA         ___|___    \
| +-----+  ATTENTION |PROCESSOR  |-+  |                  |       \____\
|                    |           |<---|------------------|        \
|                    +-----------+    |                  |_________\
|    Graphic Application Program      |                  INPUT DEVICE(S)
|                                     |
+-------------------------------------+
/SERVING\ HOST
\USING  /






Cotton                                                          [Page 4]

RFC 178            NETWORK GRAPHIC ATTENTION HANDLING          June 1971


3.3 NETWORK CONFIGURATION

   When the stand-alone configuration with standardized formats is
   implemented on a network, the organization illustrated in Figure 3
   results.  In the network configuration, the graphic application
   program and the input and output processors may be in different
   hosts.  The standardized formats become network standards, and now
   any using host with input/output processors conforming to the
   standard can access the graphic application program in the serving
   host.  The network is transparent to the graphic configuration.

3.4 NETWORK CONFIGURATION WITH INTELLIGENT TERMINAL

   The case of an intelligent graphics terminal configured in the
   network is illustrated in Figure 4.  Here, input and output
   processors are located within the terminal itself.  The using host
   serves only to connect the terminal to the network, and in the case
   of a terminal IMP, is dispensed with altogether.  Any type of
   intelligent terminal may access any graphic application program if
   its (the terminals) input and output processing routines conform to
   the network standard.  As before, the network is transparent to the
   graphic configuration.

   Figure 3 Network Configuration (Omitted due to complexity)

   Figure 4 Network Configuration with Intelligent Terminal (Omitted due
   to complexity)


4.0 INPUT DEVICES

   We now turn to a survey of graphic input devices as suggested in RFC
   87.  The survey will concern itself with the characteristics of the
   attention information presented when the device is used (rather than,
   for example, human factors considerations).

   We wish to stress at the onset that we consider all devices
   equivalent in capability.  By this we mean that with appropriate
   programming, any device can simulate any other device.  Throughout
   the survey we will illustrate typical data conversions which might be
   performed, and at times discuss how various devices may be simulated.

   It is convenient to consider the characteristics of classes of
   devices.  Information about particular commercial devices may be
   found in reference 5 and elsewhere.  Table I presents a device class
   summary.





Cotton                                                          [Page 5]

RFC 178            NETWORK GRAPHIC ATTENTION HANDLING          June 1971


4.1 PUSHBUTTONS

   Perhaps the first and most primitive class of input devices is the
   pushbutton, which presents some unique code to the system when
   depressed.  In the simplest case, the code is equivalent to the
   knowledge that the button has been pushed, and may be just a flag.

   Beyond the basic pushbutton, more advanced key devices have been
   designed in a variety of ways.  For example, each key may be
   associated with a single bit in a word or with a complex pattern
   (character or byte), multiple keys may or may not be able to be
   struck simultaneously (if so, their codes being combined in some
   defined way).

   The salient feature of the function key is that it presents two
   pieces of information to the system: the fact that a keystroke has
   occurred (which may be implicit), and some unique code related to it.

   More elaborate keyboards, be they teletypes or solid state devices
   with elaborate "overlays", are merely special cases of function keys.
   They present the same information, attention source plus a unique
   code.  The fact that such a code may be associated with a displayable
   character is at this stage only incidental.