Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Some factors which a Network Graphics Protocol must consider (RFC0192)

IP.com Disclosure Number: IPCOM000007197D
Original Publication Date: 1971-Jul-12
Included in the Prior Art Database: 2002-Mar-05
Document File: 20 page(s) / 48K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.W. Watson: AUTHOR

Abstract

It is our contention that, if computer graphics is to be widely useful, the graphics terminals must be just another type of terminal on a timesharing system with minimal special privileges. In these brief notes we outline the basic features which we feel must be available in a graphics support package to allow easy interactive graphics application programming.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 7% of the total text.

Network Working Group                                          R. Watson

Request for Comments: 192                                        SRI-ARC

NIC: 7137                                                   12 July 1971

      Some Factors which a Network Graphics Protocol must Consider

   After reading some of the RFC's on a network graphics protocol it

   seems that many are not providing general enough mechanisms to handle

   attention handling, picture structure, and other higher level

   processes involved in interactive graphics.

   Therefore for what it is worth I am sending out these rough

   introductory notes which contain ideas that I think any network

   graphics protocol must come to grips with.

   The network graphics protocol should allow one to operate the most

   sophisticated system with more general data structures and concepts

   than those described in these notes and allow very simple systems to

   function also.

Introduction

   It is our contention that, if computer graphics is to be widely

   useful, the graphics terminals must be just another type of terminal

   on a timesharing system with minimal special privileges.  In these

   brief notes we outline the basic features which we feel must be

   available in a graphics support package to allow easy interactive

   graphics application programming.

   If one examines the types of tasks in industry, government and

   universities which can avail themselves of timesharing support from

   graphics consoles, one can estimate that the large majority can

   effectively utilize quite simple terminals such as those employing

   storage tubes.  I would estimate 75% of the required terminals to

   fall in this class.  Another 15-20% of terminals may require higher

   response and some simple realtime picture movement, thus requiring

   simple refresh displays.  The remainder of terminals are needed for

   high payout tasks requiring all the picture processing power one can

   make available.  In this talk we are not considering support for this

   latter class of applications.

MAIN ASSUMPTIONS AND REQUIREMENTS FOR SYSTEM DESIGN

   The main assumptions and requirements underlying the interactive

   graphics are the following:

Watson                                                          [Page 1]

RFC 192          Some Factors which a Network Graphics      12 July 1971

      1) The user of the graphics terminal should be just another

         timesharing system user.

      2) The graphics software support should interface to existing

         timesharing programs.

      3) The software support should allow technicians, engineers,

         scientist, and business analysts as well as professional

         programmers to easily create applications using a graphic

         terminal.

      4) The software support should easily allow use of new terminals

         and types of terminals as they come on the market.

      5) The software support should be expandable as experience

         indicates new facilities are required.

      6) The software support should be portable from one timesharing

         service to another.

      7) Some form of hardcopy should be available.

MULTILEVEL MODULAR APPROACH TO SYSTEM DESIGN

   If one wants to create as system which is easy to use by

   inexperienced programmers and ultimately non-programmers, one needs

   to provide powerful problem-oriented aids to program writ...