Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!orca!undies!pmartz
From: pmartz@undies.dsd.es.com (Paul Martz)
Newsgroups: comp.graphics
Subject: Is PEX == PHIGS? [was: PEX, PHIGS, DEC5000?]
Message-ID: <1991Mar20.170615.11253@dsd.es.com>
Date: 20 Mar 91 17:06:15 GMT
References: <1991Mar20.044028.16631@ithaca.uucp>
Sender: usenet@dsd.es.com
Reply-To: pmartz@undies.dsd.es.com (Paul Martz)
Organization: Evans & Sutherland Computer Corp., Salt Lake City, UT
Lines: 63
Nntp-Posting-Host: 130.187.85.56

In article <1991Mar20.044028.16631@ithaca.uucp>, garry@ithaca.uucp (Garry Wiegand) writes:
> rthomson@dsd.es.com (Rich Thomson) writes:
> >PEX is PHIGS/PHIGS-PLUS Extensions to X, so if they are using PEX they
> >are using PHIGS ... 
> 
> No, you can use PEX without getting involved with Phigs. We are
> planning on doing this, as soon as we have been given an actual
> working Pex. 
> 
>    [...]
> 
> Garry Wiegand    ---    Ithaca Software, Alameda, California
> ...!uunet!ithaca!garry, garry%ithaca.uucp@uunet.uu.net

[Of course I can't help but jump into this discussion!]

It seems to me Rich is saying when you use PEX you are using PHIGS
because PEX protocol requests are interpreted using PHIGS semantics on
the server side.

The obvious counter-argument is presented by Garry, who says you don't
have to use PHIGS to use PEX, just write some other API that spits out
PEX protocol.

This is just quibbling: Obviously, both viewpoints are correct,
depending on how you wish to view the issue. However I think it's most
interesting to look at this from the application's view of things, and
let's see if some of this confusion can't be cut through...

If the application creates its own X window and then proceeds to call
popen_xphigs, is it still using PHIGS? Well, yes, it makes many PHIGS
calls after that. But it's not pure PHIGS -- it uses XCreateWindow (or
some variety thereof), and popen_xphigs, which is a PEX-SI specific
call to let X-cognizant applications use PHIGS. I think this is the
type of program the original poster referred to when he said he came
across some "PEX" programs. I have always thought of a PEX application
as one which *must* run under a PEX implementation of PHIGS because it
uses some X or X-related calls.

The situation is similar if an application uses the proposed PEXIM
API, which gives the application direct access to PEX's immediate mode
functionality. The application still uses PHIGS calls, but becomes
unpure, and can only port to a PEXIM implementation of PHIGS. You can
no longer refer to that application as a PHIGS application because
that is misleading. I wouldn't want to call it a PEX application
either, since that implies it would be portable to all PEX-SI based
API libraries. Let's call it a PEXIM application.

So what happens when an application uses the proposed PEXtk API from
ShoGraphics? It's not a PHIGS application -- there's not a single
PHIGS call in there. Nor is it a GL application, even though the port
would be trivial. PEX protocol is used, but the PEX-SI API is no where
in sight. I guess you'd have to	call it a PEXtk application.

A programmer who writes a PEXtk application can be completely PHIGS
ignorant, even though PEX is being used. Saying the application uses
PHIGS because it uses PEX may make sense to those of us who have
implemented PEX, but it just confuses the issue to the application
programmer -- and aren't we implementing PEX for them, anyway?
-- 

   -paul	pmartz@dsd.es.com
		Evans & Sutherland