rfc549.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 676 行 · 第 1/2 页


RFC 549               Minutes of Network Graphics        15-17 July 1973


Monday Evening, 16 July

   About 2030 seven of us met in Ken Victor's room

   Bob Sproul led the meeting and kept track of the various aspects of
   the protocol.

   Protocol topics which had been discussed during the day's meeting
   were covered again.  Most aspects were firmed up based on the day's
   discussions.  Several topics were identified for discussion in the
   morning.

   Operations on and attributes of segments were defined.

   The server should be able to enquire for various information from the
   using host.

      Whether the using host has all the features implemented (which the
      application needs).

      What input devices the human has at his disposal.

      What sort of terminal is being used, not so as to send device
      specific code to it, but so that the application does not try to
      use some graphics programming technique on a terminal which can
      not handle it (e.g., some sort of dynamics on a storage tube).

   The server may request that the using host report what segments have
   been defined, their status, and what is contained in then.  This is
   good for debugging, and also provides a limited facility of building
   a picture then dumping it to some storage medium other than a
   graphics device.

   It was pointed out that the effect of multiple changes in the display
   (replacing, inserting and deleting segments) should occur "all at
   once" when an "end batch of updates" command is received by the using
   host.

      For a refreshed display, this means keeping old and new copies of
      segments until the "batch" command is received.

      This rule may be waived if storage limitations dictate.









                                                                [Page 7]

RFC 549               Minutes of Network Graphics        15-17 July 1973


   There was considerable discussion on input.  It was felt to be the
   least firm of any aspects of the protocol.

   The meeting broke up around 0030?

Tuesday Morning/Afternoon, 17 July

   Bob Sproul presented the results of the previous evening's discussion
   to the whole meeting.

   The features required of a graphics user program under the proposed
   protocol were divided into three classes:

      Required features included segment manipulation, primitive
      graphics output operations, and response to queries from the
      server regarding what is implemented at the using host, what input
      devices the human has available, etc.

      Optional features included TTY units, reporting the contents of a
      segment back to the server at his request.

      Experimental features included Input.

         It was assumed that after some experience, experimental
         features would become either required or optional.

      A full list of required, optional, and experimental features will
      be issued as a supplement to the description of the protocol.

   A graphics server program need only implement those features which
   applications at that site make use of.

   There was some discussion regarding how and when the graphics
   protocol should be published.

      The protocol is still regarded as experimental, and we wouldn't
      want any site to assume otherwise, to their later dismay.

      Some worry was expressed about finally presenting this protocol to
      the Network Community in a form that would not frighten too many
      people.

      Ira Cotton advised us to include a glossary.

      Bob Sproul will put an initial version (skeleton) of a description
      of the graphics protocol for transformed-segmented scheme into NLS
      and will invite everybody in the group to edit it (in normal NLS
      fashion).



                                                                [Page 8]

RFC 549               Minutes of Network Graphics        15-17 July 1973


         When one does editing normally, one's ident, the date and the
         time are associated with each statement one touches.  This
         information can be seen via the viewspec (capital) K.

   There was some discussion of whether Level 0 NGP could be imbedded in
   the Transformed-segmented graphics protocol.

      One unfortunate part of NGP-0 was that an End-Picture the is not
      explicitly required in order to see something.  If it were
      required, then it could act like an end-batch-of-updates command.

         UCSB assumes that NGP-0 works like a storage tube.  They append
         a new function plot to an existing picture never having sent an
         End-Picture operation.

      This ability to append in a storage tube fashion struck the
      processors of refresh tubes as quite a drawback, because of
      implementation difficulties.

      It was decided to allow a using site to have NGP-0 compatibility,
      but not to require it.

         At least the NGP-0 opcodes would not be reused.

   Except for the End-Picture problem, and possibly also a coordinate
   system problem (coordsys), NGP-0 can be imbedded in the transformed-
   segmented protocol with the entire NGP-0 picture corresponding to a
   single segment.

   The following sites hope to achieve implementations of the
   experimental segmented protocol:

      UCSB hopes to have a server running for OLS and Signal Analysis
      (speech processing).

      SRI-ARC hopes to have NLS operate in this protocol.

      MIT-DMCG may have some simple serving programs.

      Several people plan to implement user programs, at least as far as
      the required features go.

   (coordsys) A discussion arose concerning what coordinate system
   should be used in sending graphics output primitives from the server
   to the user.

      The following problems were addressed:




                                                                [Page 9]

RFC 549               Minutes of Network Graphics        15-17 July 1973


         What happens if the display segment terminal screen area to be
         used by the application is not rectangular?

         What happens if the basic unit delta X is not the same as the
         unit delta y? The application might want a 45 degree line to
         really be at 45 degrees.

      Various answers to the first question:

      Use the largest square within the rectangle (centered?, adjusted
      to the left, top, right, or bottom?)

      Use the smallest square surrounding the rectangle. (How is the
      rectangle positioned in the square?)

      NGP-0 standard coordinates (-1/2 to +1/2) used and mapped into the
      whole rectangle.

      The user reports left, bottom, right, and top physical coordinates
      and the server sends coordinates within the range given.

         This is compatible with the attitude that the transformed (!)
         segmented graphics data are sent.

         It is also saves the using host (which might be an Imlac) from
         doing a multiply.

   John Pickens observed that if a graphics server for a finicky
   application transmits characters as strokes, then the application is
   assured of having the characters positioned in exactly the right
   place (e.g., for a numeric label on a tic mark on the axis of a
   graph.  If characters are sent as text (not strokes) positioning is
   not necessarily guaranteed.

   Ken Victor and Jim Michener will look into ways of keeping the NGG
   apprised of progress (in terms of what sites have
   experimental/operational graphics protocol servers or user programs)
   using a pointer file in the NIC.

   The next NGG meeting is tentatively scheduled for the first Sunday in
   February 73, at 8PM.  It will either be at the NIC or partly there
   and partly at Xerox PARC.

   The meeting was adjourned at 1500.







                                                               [Page 10]

RFC 549               Minutes of Network Graphics        15-17 July 1973


Appendix: Meeting Participants/ Affiliation/ Online mailing address/
   Attendance (S=Sunday, M=Monday day, E=Monday Evening, T=Tuesday)

   Steve Bunch     ILL-ANTS
      BUNCH@ISI
      SMT

   Dan Cohen     Harvard
      DCOHEN@ISI or COHEN@HARVARD
      SMET

   Ira Cotton     National Bureau of Standards
      NBS-TIP@NIC attention Ira Cotton
      SMET

   John Day     ILL-ANTS
      S

   David Egli     CAD/CAM (Fort Monmouth)
      ECOM@BBN
      SMT

   Jim Hansen     ILL-ANTS
      HANSEN@ISI
      SMT

   Jim Hart      NASA/Ames
      MT

   Austin Henderson     Lincoln Labs
      DAH@TX2 or DAH@BBN
      SMET

   Steve Holmgren     ILL-ANTS
      HOLMGREN@ISI
      MT

   John Jervert     CAD/CAM (Fort Monmouth)
      ECOM@BBN
      SMT

   Alex McKenzie     BBN
      AAM in the journal or MCKENZIE@SRI-ARC
      SMT

   James Michener     MIT-DMCG
      JCM in the journal or JCM@DMCG
      SMET



                                                               [Page 11]

RFC 549               Minutes of Network Graphics        15-17 July 1973


   John Pickens     UCSB
      JRP in the journal or UCSB@ISI (attn: John Pickens)
      MT

   Ken Progran     MIT-Multics
      Pogran.CompNet at MIT-MULTICS
      SMT

   Bob Sproul XEROX
      SPROUL@MAXC
      MET

   Elaine Thomas     BBN
      THOMAS@BBN
      SMET

   Ken Victor     SRI-ARC
      VICTOR@NIC
      SMET


         [ This RFC was put into machine readable form for entry ]
               [ into the online RFC archives by Via Genie ]




























                                                               [Page 12]