rfc285.txt

中、英文RFC文档大全打包下载完全版 .

typing or wishes to begin typing. NETCRT tries to maintain good man-
machine interaction by controlling the state of the terminal.

        I have refrained from commenting on the various proposals as I
summarized them because I don't think that it would have been in line
with what I am trying to do in this paper. I think that there is a need
to consider an overall model of the graphic system we are trying to
design. Previous proposals have dealt with some set of details without
identifying with a general model, producing good ideas for
implementation of details but not considering how the whole will fit
together. Thus I would like to propose a model for our graphics system.
It will contain many protocols and leave many areas to be discussed
further, but it will provide a starting point from which work can be
done along simple lines, and yet not exclude the later inclusion of more
sophisticated abilities.

        Figure 1 shows a block diagram of information flow. The PROCESS
indicates a graphics application program which is running on a computer
in the net. Its associated INPUT and OUTPUT routines can be thought of
as being a set of subroutines loaded with the main PROCESS or as
separate and running elsewhere serving many users. At the other end of
the loop are a set of INPUT and OUTPUT drivers for the DISPLAY which is
being used to display the graphics information. The information flowing



                                   4





RFC 285  NIC 8271


from the PROCESS to the DISPLAY is drawing information for the building
and manipulation of pictures. The information flowing from the DISPLAY
to the PROCESS is attention information. The Graphic Data Base
associated with the main PROCESS is that which is constructed when the
picture is being drawn by the PROCESS or when the picture is being drawn
by local processing and attention messages tell the PROCESS what has
been done to the picture. This data base need not contain more
information that the PROCESS is willing to work with, and in fact need
not contain anything if no picture interaction is to be done. The
Graphic Data Base associated with the DISPLAY drivers is built by
themselves so that the OUTPUT driver can handle attentions from the
DISPLAY without requiring the main PROCESS to be able to do this and for
the INPUT driver to use when modifying the picture based on what is
actually being displayed. The information flowing to and from the main
PROCESS is the sort which is passed or received as parameters to
procedures. The INPUT and OUTPUT routines translate to and from
respectively a network standard graphics protocol which is sent out over
the net to the INPUT and OUTPUT display drivers whose responsibility it
is to translate the standard message into the appropriate byte stream to
drive the DISPLAY or translate the attention from the DISPLAY into a
network standard message. The DISPLAY is assumed to handle its own
refreshing if it requires any, so that there will be as little apparent
difference between refreshed and non-refreshed displays as is possible.

        This model provides for both simplicity of use for those doing
simple things and power which is needed for those doing sophisticated
interactive graphics. It can be used with a minimum of effort and
overhead by setting runtime conditions to indicate that no interactive
graphics will be done and all associated processing should be skipped,
while still enabling other PROCESSes to do high powered graphics without
going to a completely different set of routines and rules.

        Due to the existence of two separate data bases, which must be
kept up-to-date with each other there are two modes of operating this
model. For lack of better names let us call them PROGRAM graphics and
LOCAL graphics. The former indicates that the picture being displayed is
constructed by the main PROCESS and all input from the user at the
display is solicited, thus the DISPLAY data base is only updated after
and as a result of action by the main PROCESS. The latter indicates that
the user at the display is directing the construction of a picture by
means of function buttons and drawing tools, the DISPLAY data base is
updated immediately and the main PROCESS is notified of the change so
that it may keep up, but it does not perform manipulations of the
picture unless requested to do so by the DISPLAY OUTPUT driver; this can
be as a result of a request to perform some function that the DISPLAY
INPUT/OUTPUT drivers can do by themselves or a request by the user to
have the main PROCESS perform a non-standard function on the picture.




                                   5





RFC 285  NIC 8271


        The main purpose of this design is to allow greatest generality
of graphic configurations rather than minimum response time. The design
for an optimum requires more exact specification of the hardware
configuration and the proposed usage. Since neither of these variables
can be known, and in fact our attempt at generality keeps us from even
guessing very closely at them, we must provide intelligent INPUT/OUTPUT
drivers that will know how to split the processing load between
themselves and the main PROCESS as a function of what kind of DISPLAY
they are driving, rather than attempting to design in an optimum
breakpoint.

        The Graphics Protocol should specify the format of the messages
which are transmitted between the INPUT and OUTPUT routines and drivers.
These messages can be divided as previously mentioned according to their
direction and content, i.e. drawing messages and attention messages.
Since it is often desired to intermix graphics and text there should be
a distinguishing message header for all graphics messages. Then a byte
to specify the type of information contained in the body of the message,
a count of the bytes in the body, and finally the body itself. Virtually
all of the necessary message types have been indicated in the previous
RFCs and I will not list them here, except to note that attentions now
include requests for processing that the drivers could not do.

        To summarize, I believe that a simple model is enough to enable
the design of both sophisticated interactive graphics and low effort
non-interactive graphics. The primary reason for this is that our major
interest is not minimum response, but rather maximum configuration
mixes. There are opportunities to use software sharing and data
reconfiguration services when building INPUT/OUTPUT routines and
drivers. Much detailed work remains to be done, but with a basic model
in sight providing a framework to hang proposed ideas on for evaluation,
work should be able to proceed more smoothly.



















                                   6





RFC 285  NIC 8271


         +---------+                  +--------+
         ! INPUT   !                  ! OUTPUT !
      +--! routine !<------||---------! driver !<--+
      !  +---------+                  +--------+   !
      !                                   ^        !
      V                                   !        !
 +---------+---------+      +---------+   !   +---------+
 !         ! Graphic !      ! Graphic !   !   !         !
 ! PROCESS ! Data    !      ! Data    !<->!   ! DISPLAY !
 !         ! Base    !      ! Base    !   !   !         !
 +---------+---------+      +---------+   !   +---------+
      !                                   !        ^
      !                                   V        !
      !  +---------+                  +--------+   !
      !  ! OUTPUT  !                  ! INPUT  !   !
      +->! routine !-------||-------->! driver !---+
         +---------+                  +--------+

                         Figure 1







       [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Ian Redfern 4/99 ]























                                   7