rfc965.txt

RFC 的详细文档！

                 +-----|------+        +-------------+
                       |---------->    |   DEVICE-   |
                 +------------+        | INDEPENDENT |
                 |  DEVICE    |        |   GRAPHICS  |
                 |  DEPENDENT |  <---> |   SERVICES  |
                 |  GRAPHICS  |        |             |
                 |  SERVICES  |        |             |
                 +-----|------+        |             |
                       |               |             |
                       v               |             |
                 +------------+        |             |
                 |    DEVICE  |        |             |
                 |  DRIVERS   |        |             |
                 +------------+        +-------------+

                 FIGURE 1 - THE BASIC GRAPHICS PIPELINE
                        IN A CONFERENCING SYSTEM





















Aguilar                                                        [Page 22]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


+------------+    +------------+                 +------------------+
|APPLICATION |    |   OTHER    |                 |    TRANSMIT      |
|   DATA     |    |   MEDIA    |                 |       ACK        |=>
| STRUCTURES |    |------------|     +-----+     | SEPARATE TRAFFIC |=>
+-----|------+    | CONFERENCE |     |     |===> |    BATCHING      |=>
      |---------->|APPLICATION |     |     |     |   TIMESTAMPING   |
                  |  GRAPHICS  |     |     |     +------------------+
      |---------->|------------|     |     |
      |           | PIGCF L, U | <---|     |     +------------------+
+-----|------|    | INTERPRETER|     |     |     |     RECEIVE      |
| LANGUAGE   |    +------------+     |  R  |     |  MERGE TRAFFIC   |<-
| BINDING    |    | PIGCF U    |===> |  O  | <---| CHECK TIMESTAMPS |<-
+-----|------+    |  GENERATOR |     |  U  |     | ERROR CORRECTION |<-
      |           +------------+     |  T  |     |                  |
      ------------------|            |  E  |     +------------------+
+------------+    +-----V------+     |  R  |
|  DEVICE    |    |  DEVICE    |     |     |     +------------------+
| DEPENDENT  |    |INDEPENDENT |     |     |====>|                  |
| GRAPHICS   |<-->|  GRAPHICS  |     |     |---->|    CONFERENCE    |
| SERVICES   |    |  SERVICES  |     |     |     |       RECORD     |
|            |    |            |     |     |     |                  |
+-----|------+    |------------|     |     |     +------------------+
      |           |    GKSM    |     |     |
      v           | INTERPRETER|<--- |     |       <--- INCOMING PIGCF
+------------+    +------------+     |     |
|   DEVICE   |    |    GKSM    |     |     |       ===> OUTGOING PIGCF
| DRIVERS    |    | GENERATOR  |===> |     |
+------------+    +------------+     +-----+

FIGURE 2 - A CONFERENCING SOFTWARE ARCHITECTURE FOR PROCESSING PIGCF

VI.  CONCLUSIONS

   Teleconferencing and other multi-media applications will be part of
   the communication resources available to organizations in the near
   future. This will prompt computer graphics and computer communication
   practitioners to address the issue of application-to-application
   graphics communication. A key element of the issue is a protocol, and
   a key component of the protocol is a data format. We have presented
   the operational requirements for such a protocol and have proposed a
   format that fulfills these requirements.

   At present, none of the existing or emerging graphics standards can
   be used as the needed protocol or as a format for the protocol, but
   this may change as the standards evolve.  We are monitoring the
   standards development and will study the use of some of them as a
   format basis, in particular the CGI.  Nevertheless, the computer


Aguilar                                                        [Page 23]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


   communication community badly needs experience with multi-media
   conferencing implementations. In order for these applications to
   happen, one can base a graphics communication protocol on an official
   or on a de-facto standard that is likely to gain wide use thus
   assuring interoperability with a broad user base.  We believe that,
   by using the GKSM session metafile, we are moving in the proper
   direction.

   Planning the software architecture for generating and interpreting
   the proposed PIGCF has brought up some problems we will confront as
   we continue our work toward the development of a complete graphics
   protocol.  This is being done as part of the SRI on-going program in
   multimedia communications.  Within this program, we are implementing
   a simple multi-media conferencing prototype and will design a more
   complete one.  The experience from both exercises will be a valuable
   input to the protocol architecture design.

































Aguilar                                                        [Page 24]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


APPENDIX A

   Excerpt from "Draft Proposal: Graphical Kernel System" [14]

   E.2  Metafile Based on ISO DIS7942

      This metafile may be categorized as one which aims to provide a
      means of recording the exact sequence of function calls made to
      GKS. Its functional capability covers the entire range of GKS
      output functions, from level m to level 2. It is, therefore,
      suitable for applications where the individual graphics actions
      need to be 'played back', perhaps with selective graphical editing
      being done by the interpreter.

      Two encodings have been specified for this metafile. One encoding
      is inefficient for many applications. The second allows an
      unspecified binary format. The remainder of this IGCF appendix
      gives full details of these metafile structures and encodings.

      E.2.1 File Format and Data Format

         The GKS metafile is built up as a sequence of logical data
         items. The file starts with a file header in fixed format which
         describes the origin of the metafile (author, installation),
         the format of the following items, and the number
         representation. The file ends with an end item indicating the
         logical end of the file. In between these two items, the
         following information is recorded in the sense of an audit
         trail:

            a)      workstation control items and message items;

            b)      output primitive items, describing elementary
                    graphics objects;

            c)      attribute information, including output primitive
                    attributes; segment attributes, and workstation
                    attributes;

            d)      segment items, describing the segment structure and
                    dynamic segment manipulations;

            e)      user items.






Aguilar                                                        [Page 25]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


         The overall structure of the GKS metafile is as follows:

            FILE:     |file  |item|---|item|---|end |
                      |header| 1  |   | i  |   |item|

            ITEM:     |item   |item data record|
                      |header |                |

            ITEM      |'GKSM'  |identification|length of item data|

            HEADER:   |optional|    number    |       in bytes    |

         All data items except the file header have an item header
         containing:

            a)      the character string 'GKSM' (optional) which is
                    present to improve legibility of the file and to
                    provide an error control facility;

            b)      the item type identification number which indicates
                    the kind of information that is contained in the
                    item;

            c)      the length of the item data record.

         The lengths of these fields of the item header are
         implementation dependent and are specified in the file header.
         The content of the item data record is fully described below
         for each item type.

         The metafile contains characters, integer numbers, and real
         numbers marked (c), (i), (r) in the item description.
         Characters in the metafile are represented according to ISO 646
         and ISO 2022. Numbers will be represented according to ISO 6093
         using format F1 for integers and format F2 for reals. (Remark:
         Formats F1 and F2 can be written and read via FORTRAN formats I
         and F respectively.)

         Real numbers describing coordinates and length units are stored
         as normalized device coordinates. The workstation
         transformation, if specified in the application program for a
         workstation writing a metafile of this format, is not performed
         but WORKSTATION WINDOW and WORKSTATION VIEWPORT are stored in
         data items for later usage. Real numbers may be stored as
         integers. In this case transformation parameters are specified
         in the file header to allow proper transformation of integers
         into normalized device coordinates.


Aguilar                                                        [Page 26]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


         For reasons of economy, numbers can be stored using an internal
         binary format. As no standard exists for binary number
         representation, this format limits the portability of the
         metafile. The specification of such a binary number
         representation is outside the scope of this document.

         When exchanging metafiles between different installations, the
         physical structure of data sets on specific storage media
         should be standardized. Such a definition is outside the scope
         of this standard.

   E.3  Generation of Metafiles

      Table E1 contains a list, by class, of all GKS functions which
      apply to workstations of category MO, and their effects on this
      GKSM. In the table, GKSM-OUT is a workstation identifier
      indicating a workstation writing a metafile of this format.

      The concepts of clipping rectangle and clipping indicator are
      encapsulated in one metafile item which specifies a clipping
      rectangle. This item is written to the metafile on activate
      workstation with the values (0, 1, 0, 1), if the clipping
      indicator is OFF, or the viewport of the current normalization
      transformation, if the clipping indicator is ON. If the viewport
      of the current normalization transformation is redefined or a
      different normalization transformation is selected when the
      clipping indicator is ON, a further clipping rectangle item is
      wr