rfc965.txt

RFC 相关的技术文档

      tracking its evolution, and we are interested in defining a format
      based on the CGI.

      Finally, the Initial Graphics Exchange Specification [11] is not
      aimed at our primary area of interest. The IGES defines standard
      file and language formats for storing and transmitting
      product-definition data that can be used, in part, to generate
      engineering drawings and other graphical representations of
      engineering products.  Besides the CAD orientation of IGES, the
      graphical output function may be secondary to other goals like
      transmitting numerical-control machine instructions.

II.  OPERATIONAL REQUIREMENTS AND USABILITY

   The main goal of this paper is to lay the groundwork for the
   development of a vector graphics format to be used as a basis for an
   on-line graphical communication protocol. We call such a format an
   "interactive graphical communication format," or IGCF. In this
   section we describe some operational requirements and usable
   characteristics for an IGCF.

   A. Interoperation of Heterogeneous Systems

      A first functional requirement is that an IGCF must permit
      communication among heterogeneous graphical systems differing both
      in the hardware used and in the software of their graphics


Aguilar                                                         [Page 6]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


      application interfaces. This is a fundamental for attaining
      communication among similar graphical application programs running
      on dissimilar hardware and using dissimilar graphics interface
      packages. Some examples of such application programs are graphics
      editors, CAD systems, and graphical database retrieval programs
      communicating with other editors, CAD programs, and graphical
      databases, respectively.

   B. Picture Capture

      A required characteristic of an IGCF is that it must be usable for
      the exchange of static graphic pictures, i.e. for picture capture;
      yet, it must not be restricted to final picture recording only.
      There will be picture exchanges as part of the interactive
      communication, and we anticipate the need to record the state of a
      picture at some points during the on-line graphics engagement. We
      foresee the creation of graphical IGCF libraries containing object
      definitions and pictures for inclusion in new pictures. Since
      metafiles have been used for a long time to capture pictures,
      there is a strong motivation to base an IGCF on a metafile
      standard in order to secure compatibility with a large number of
      metafile sources and consumers.

   C. Prompt Transmission

      In some forms of interactive graphical communication, like
      audiographics conferencing, it is critical to convey across users
      the real-time nature of the interaction. This dictates that object
      creations and manipulations be transmitted as they happen rather
      than as a final result since a substantial part of the information
      may be transmitted concurrently with the construction or operation
      of an object, possibly through associated media like voice. Since
      both construction and manipulation processes have to be
      transmitted, there is a limit to the number of intermediate states
      that can be economically transmitted.

      A third requirement is, therefore, that the IGCF elements provide
      fine "granularity" to convey the dynamics of the constructions and
      manipulations. We believe that it is sufficient that the IGCF have
      basic construction elements like polygons, markers, polylines, and
      text strings and that it transmit them only when they are
      completed; i.e., it is not necessary to transmit partial
      constructions of such elements.

      The problem for manipulations extends beyond an IGCF. Whereas we
      know that an IGCF should include segment transformations, segment
      highlighting and segment visibility on/off, the transmitter must


Aguilar                                                         [Page 7]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


      decide how often to sample an on-going transformation and transmit
      its current state. The choice of a sampling frequency will depend
      on the available transmission bandwidth.

   D. Low Traffic Volume

      In many of the applications we envision, coordinate graphics will
      be transmitted over narrow bandwidth channels, and thus it is
      essential to minimize traffic. Accordingly, several requirements
      are imposed on an IGCF to take advantage of the characteristics of
      the graphics communication intercourse and architecture in order
      to minimize traffic.

      An IGCF can help reduce traffic by including the basic geometric
      objects from which so many other objects are built. Moreover, an
      IGCF should permit the use of objects for the creation of more
      complex objects; since reuse is very common, the result is a
      reduction of traffic and storage cost.

   E. Preservation of Application Semantic Units

      A related requirement is that an IGCF must include elements to
      represent graphical objects corresponding to real world entities
      of the intended applications. For example, in a Navy application,
      the entities of interest are carriers, submarines, planes, and the
      like. We want to communicate such semantic units across systems
      and to treat them as unitary objects because, in many
      applications, communication is based on creating and operating
      such units. If an IGCF has elements to represent such semantic
      units, the communication traffic decreases because the entity
      definitions can be transmitted only once and then reused, and
      because the entities are manipulated as units rather than
      separately manipulating their components.

      It turns out that there is a small set of primary operations that
      can be applied to a graphical object, and an IGCF must have
      elements representing such operations. In contrast to dumb
      graphics terminals receiving screen refresh information from a
      host, we foresee graphical communication taking place among
      intelligent workstations that can exchange encoded operations,
      interpret them, and apply them to objects stored locally.

   F. Transmission Batching

      We previously indicated the desirability of conveying to the human
      users the real-time tempo of interactive graphics exchanges.
      However, it is possible to do so without having to transmit


Aguilar                                                         [Page 8]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


      immediately all IGCF elements. As a matter of fact, IGCF elements
      should be divided into those causing a change on a displayed
      picture and those that do not, although both classes may cause
      changes to the stored graphical data structures.

      It is only necessary to transmit immediately those elements
      causing a visible change on a displayed picture because they are
      the ones whose reception and interpretation delivers information
      to a human user. The second class of elements can be batched and
      queued for transmission until one element of the first class is
      submitted. We call the first class update Group-1, and the second,
      update Group-2.

      The aforesaid division is quite important for packet
      communications because each packet contains a hefty amount of
      overhead control traffic. It is therefore mandatory to batch, into
      a packet, as much client data as possible in order to reduce total
      traffic. The batching units can be varied in size according to the
      network traffic and response time of conference hosts. During
      congested periods, the units may have to be increased, thus
      lowering the number of messages, and then reduced when congestion
      eases, thus increasing the number of messages.

   G. Simple Translation Between IGCF and User Interface

      According to the first requirement, an IGCF must permit the
      interoperation of related heterogeneous graphics applications.
      Such interoperation has, as an objective, the communication
      between human users or between a human and a database.
      Correspondingly, the interoperation involves a mapping between the
      user interface commands and the IGCF elements. It is not advisable
      to use the commands themselves as the IGCF elements; otherwise the
      exchange would depend on the communicating systems, and every pair
      of communicating systems would require an ad-hoc protocol.

      An additional usability characteristic is that there must be a
      simple mapping between IGCF elements and the actions represented
      by the user interface commands employed for graphical
      communications. This simplicity is a must because every
      communicating graphical system must have a translator that ideally
      should be very simple. It seems that the inclusion of command
      sequence delimiters in the IGCF helps the simplicity since the
      delimiters permit keeping a smaller amount of state information
      for processing an IGCF stream.

      We have verified the mapping from one set of commands for
      audiographics conferencing to the IGCF proposed in this paper. The


Aguilar                                                         [Page 9]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


      mapping from user interface commands to IGCF can be done in a
      direct and efficient manner; on the other hand, the reverse
      mapping, from IGCF to user interface commands, is a more difficult
      task. We anticipate that, in order to improve performance, we will
      have to map the IGCF elements to calls to lower level subroutines
      implementing the user interface actions. Whereas such mapping is
      conceptually no more complex than translating IGCF to the commands
      themselves, it will require considerably more programming.

III.  ELEMENTS OF AN IGCF

   IGCF Element Classes

      In this section we list the classes of elements that we believe an
      IGCF should have in order to exchange vector graphics under the
      requirements of the previous section. The classes correspond to
      the common function classes in computer graphics interfaces, and
      each contains elements corresponding to interface primitives and
      attributes. We do not list the elements for each class because
      they are exemplified by the elements in the proposed IGCF.

      In the following list, two categories of functions are missing:
      functions used to query the status of a graphics system, and input
      functions. As a matter of fact, an IGCF only needs to have
      elements representing actions that cause a change in the state of
      the communicating graphical systems, and the inquire functions
      obviously do not change their state. Even though an input function
      executed at the transmitting end causes a local change, it is not
      necessary to transmit the input command itself. The receivers only
      need to get the data input, in IGCF representation, and they can
      process the data in any manner, maybe simulating local input
      actions.

      Control

         Elements for workstation: initialization, control and
         transformation; and elements for normalization transformation.
         (The normalization and workstation transformations can be used
         to implement zooming.)

      Primitive attributes

         Elements for primitive, segment, and workstation attributes.

      Output primitives

         Elements for output primitives.


Aguilar                                                        [Page 10]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


      Segmentation

         Elements for basic segmentation and workstation independent
         segment storage.

         Object manipulations can be implemented with segment
         transformations. Object insertion can be implemented using
         segment recall and segment visibility. Object deletion can be
         implemented using segment deletion and segment visibility.
         Object selection can use segment highlighting as feedback to
         the user.

      Dynamics

         A considerable part of the graphical information exchanged
         through an IGCF will be in the form of pointer movements over a
         background picture. Pointer tracking is used to transmit points
         sampled from a graphical pointer trace in order to reproduce,
         at the receivers, the movement of the pointer at the sender
         site. This can be done either by just moving the cursor or by
         tracing its movement with a line. Rubber band echoes are used
         to signal areas, routes, and scopes in a highly dynamic way.
         These are indicated by an echo reference point and a feedback
         point.

   Hierarchical object definitions

      The requirement for preserving application semantics dictated that
      an IGCF include the means to represent objects that stand for
      application entities, and to manipulate such entities as graphical
      units. Furthermore, the low-traffic-volume requirement called for
      the use of already existing objects for the creation of new ones.

      One way to meet the aforesaid requirements is by including in an
      IGCF the means to represent object hierarchies. In such a
      hierarchy an object is a set of output primitives associated with
      a set of attribute values or a set of lower-level objects, each
      associated with a composition of transformations [12].

      Graphics segments can be used to implement objects in the lowest
      level of a hierarchy. The definition of a higher-level object can
      be represented by sequences of IGCF elements describing the
      definition process. Such a definition can be done by instantiating
      lower-level objects with specific transformation parameters. Thus
      an IGCF must incorporate brackets to mark the beginning and end of
      object definitions, object instantiations, and object