Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsd!sdcsvax!ucsdhub!hp-sdd!andrea
From: andrea@hp-sdd.hp.com (Andrea K. Frankel)
Newsgroups: comp.graphics
Subject: Re: Michener's History of PHIGS
Message-ID: <1909@hp-sdd.hp.com>
Date: 10 Apr 89 19:46:59 GMT
References: <427e35c1.137b8@apollo.COM>
Reply-To: andrea@hp-sdd.UUCP (Andrea K. Frankel)
Organization: Hewlett-Packard, San Diego Division
Lines: 79

In article <427e35c1.137b8@apollo.COM> tbg@apollo.COM (Tom Gross) writes:
>Mich's version of PHIGS early history
>Jim Michener
>4/7/89
>
>The name PMIG (I do not believe it was ever called PMIGS) referred
>to the Programmer's Minimal Interface to Graphics.  It was definitely
>not related to the development of PHIGS.  It was an attempt to cut
>GKS functionality (which some judged to rich) down to about 30 functions.
>GKS at the time had over 100 functions. Today's GKS (X3.124-1985) has about
>186 functions.
>
>I believe the name PHIGS was adopted after some discussion of PMIG, although
>I am not positive.  In this light I would say that the "P.I.G." of PHIGS
>came from PMIG.  The flow might have been in the opposite direction.
>PMIG was abondoned around 1982, I believe.

I joined the committee just after all this happened, but the guy at the
next desk who was our X3H3 rep kept me entertained with the ongoing soap
opera:

The early work on API's stemming from SIGGRAPH CORE was, just about from
the start, divided into two efforts colloquially called "small CORE" and
"large CORE" among the standards workers.  These were respectively
acronymmed as PMIG and Programmers' Interface to Graphics, or PIG.
There was all sorts of good-natured ribbing between the two groups -
small CORE calling the large CORE "pig" because it was such a resource
hog, large CORE teasing small CORE folks that PMIG spelled backwards was
"gimp" which was more descriptive ;@) There were all sorts of "tail
wagging the dog" arguments between the two groups, who eventually
figured out that you can't retain autonomy in making design decisions in
each group if you're also supposed to maintain compatibility (brilliant,
eh?).

PIG quickly became PHIGS (thank goodness - who could ever market a
product called [company name]-PIG?), since the hierarchy was one of the
key design distinctions between that and GKS, which is also a
programmer's interface to graphics.

PMIG wasn't exactly abandoned.  The higher levels of management in the
standards-making hierarchy called into question why we (X3H3) were
continuing to work on a standard which appeared to overlap substantially
the ISO standard GKS, and called upon X3H3 to justify or abandon the
work.  Although PMIG as a project was abandoned, it lived on as "Level
M" (for minimality) in the ANSI GKS standard; this Level M does not
appear in the ISO GKS standard.

As you might guess, many of the folks who had worked long and hard on
PMIG and really objected to the basic model of GKS were somewhat
discouraged about having to give up their pet project, and even more
disgruntled that it was they who were given the task of "ANSI-izing" GKS
(i.e., making the ISO standard into an ANSI standard).  These same folks
had probably not worked as hard as they might have to effect changes in
GKS while it was possible, because GKS was perceived as a European
standard unrelated to what we in the U.S.  were doing.  By the time PMIG
was "revectored" into ANSI GKS Level M, it was too late to do much about
major design issues in GKS, and we had to be content with trying to
band-aid the worst problems at the ISO level or putting in a few VERY
minor differences in the ANSI version.  (Of course, those of us in
companies which do a sizable portion of our business in the
international market really prefer to see a global approach to
standards, and try hard to minimize differences between ANSI and ISO
standards.)

This bit of history was a major factor in the subsequent direction taken
by X3H3, of pursuing almost all work primarily as international
standards with the intent to have identical ANSI standards adopted
nearly simultaneously.  It's much slower, more political, and more
frustrating (because of less direct control) than simply doing ANSI
standards, but it does ensure that we don't get into the same pickle
again.  (Different pickles, yes, same pickle, no ;@)

Andrea Frankel, Hewlett-Packard (San Diego Division) (619) 592-4664
	"wake now!  Discover that you are the song that the morning brings..."
______________________________________________________________________________
UUCP     : {hplabs|nosc|hpfcla|ucsd}!hp-sdd!andrea 
Internet : andrea%hp-sdd@hp-sde.sde.hp.com (or @nosc.mil, @ucsd.edu)
CSNET    : andrea%hp-sdd@hplabs.csnet
USnail   : 16399 W. Bernardo Drive, San Diego CA 92127-1899 USA