Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!newstop!exodus!atticus
From: gds@atticus (Greg Schechter)
Newsgroups: comp.graphics
Subject: Re: PEX using PHIGS (was Re: PEX, PHIGS, DEC5000?)
Message-ID: <10167@exodus.Eng.Sun.COM>
Date: 21 Mar 91 00:27:26 GMT
References: <1991Mar15.190013.7415@neon.Stanford.EDU> <1991Mar17.235026.4718@dsd.es.com> <10030@exodus.Eng.Sun.COM> <1991Mar19.211031.29928@dsd.es.com>
Sender: news@exodus.Eng.Sun.COM
Reply-To: gds@atticus (Greg Schechter)
Organization: Sun Microsystems - Graphics Technology Group - Mountain View, CA
Lines: 84
In-reply-to: rthomson@mesa.dsd.es.com (Rich Thomson)

cpetterb@es.com (Cary Petterborg) writes:

> Note what Rich says, "if you are using PEX you are using PHIGS."  He
> is correct in this because currently there is no other application
> interface to PEX, but PHIGS.  Using PEX (the extensions to X, not X)
> implies that you are dealing with the extensions that are only available
> through PHIGS, unless you are crazy enough to set up the protocol packet
> yourself. (not a good idea unless you REALLY know what you are
> doing)

But this is only a temporary situation.  Presumably, other application
interfaces will soon be ported so as to emit the PEX protocol.
Potential candidates for this are GKS, Sun's XGL, SGI's GL, HP's
Starbase, Stardent's Dore, and most other non-pixel-based graphics
packages.

In article <1991Mar19.211031.29928@dsd.es.com>, rthomson@mesa (Rich Thomson) writes:

>    o PEX
>	PEX is the PHIGS Extensions to X.  Seems to me that the very
>	name implies that PEX is PHIGS.  Like most extensions to X,
>	PEX has two sides: the client side and the server side.  The
>	core of the extension is really the protocol as Greg points
>	out, but in reality PEX means alot more to users than just the
>	protocol.  It is possible to write programs using only the
>	protocl definition, but this is painful at best.
>
>	In server land, the PEX protocl is implemented via a number of
>	resources that provide some basic functionality.  The document
>	``PEX Introducion and Overview'', version 3.20, dated 8 June
>	1989 starts as follows:
>
>	    ``PEX (a PHIGS/PHIGS+ Extension for X) is a 3D graphic
>	    extension to the X Window System(*) that efficiently
>	    supports PHIGS and PHIGS+.''
>
>	    (*) X Window System is (TM) by MIT.
>
>	That indicates to me that no matter how you are encoding the
>	protocol, you are using PHIGS.

To me, this indicates that if you're using PEX, you're using a
protocol that was designed to efficiently support PHIGS, but not that
you're using PHIGS itself.

>       That is to say that in the
>	server, PEX implements the functionality and semantics defined
>	by the PHIGS and PHIGS-PLUS standards.

There are many things in PHIGS and PHIGS PLUS which cannot be done via
PEX.  Some of these are input (PHIGS has a very rich input model, PEX
has non), archiving (PEX knows nothing about archiving), and the PHIGS
PLUS color mapping semantics (the semantics of the PEX color mapping
is quite different).

I guess the problem that I have with the statement "If you're using PEX, 
you're using PHIGS" is that it suggests that if I've got a machine with a 
PEX server on it, I somehow have access to PHIGS.  This is just not true.
You need to have a PHIGS library which implements these other things that 
PEX does not provide, and which also provides a language binding for the
features that the server has built in to it.

>>On the other hand, distributed implementations of PHIGS may use PEX to
>>achieve their distributivity.  This is particularly true if a PHIGS
>>implementation wants to be able to communicate with a variety of
>>vendors' window servers.  For example, a PHIGS implementation running
>>on a Sun may open PHIGS workstations on the local Sun, a remote Sun
>>running a PEX server, and a remote 3rd party machine running a PEX
>>server.

>Again, I think you're confusing the API (language binding in ANSI
>jargon) with PHIGS (the standard).

How so?


--- Greg

=============================================================================
= Greg Schechter                                  Graphics Technology Group =
= Sun Microsystems, Inc	    	    	    	    	  Mailstop MTV21-04 =
= 2550 Garcia Avenue                                      Mountain View, CA =
= gschechter@Eng.Sun.COM    	    	    	    	     (415) 336-6950 =
=============================================================================