Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!orca!mesa!rthomson From: rthomson@mesa.dsd.es.com (Rich Thomson) Newsgroups: comp.graphics Subject: Re: PEX using PHIGS (was Re: PEX, PHIGS, DEC5000?) Message-ID: <1991Mar19.211031.29928@dsd.es.com> Date: 19 Mar 91 21:10:31 GMT References: <1991Mar15.190013.7415@neon.Stanford.EDU> <1991Mar17.235026.4718@dsd.es.com> <10030@exodus.Eng.Sun.COM> Sender: usenet@dsd.es.com Reply-To: rthomson@dsd.es.com (Rich Thomson) Organization: Design Systems Division, Evans & Sutherland, SLC, UT Lines: 107 Nntp-Posting-Host: 130.187.85.21 In article <1991Mar17.235026.4718@dsd.es.com>, I said: :So, if you are using PEX you are using PHIGS. In article <10030@exodus.Eng.Sun.COM> gds@atticus (Greg Schechter) writes: >Actually, this is not true. PEX is simply a protocol, just like X. I have had this discussion via e-mail with Spencer Thomas (who could be considered a PEX 'guru') already. There are several confusing issues here: o PHIGS/PHIGS-PLUS (Usually when one says "PHIGS", they mean both PHIGS and PHIGS-PLUS [PLUS = ``Plus Lumiere Und Surfaces'' which gives you lighting and shading]) PHIGS is defined via a set of abstract functions and associated semantics. The standard only defines these, language bindings determine the API. Currently there are DIS (draft international standard) bindings for C and there is an approved binding for FORTRAN. [I am recalling this from memory, but I believe it to be correct; if it isn't, I'm sure some astute news reader will correct me ;-] 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. That is to say that in the server, PEX implements the functionality and semantics defined by the PHIGS and PHIGS-PLUS standards. Now by virtue of the PEX implementation, it is possible to do things not defined by the functionality of PHIGS. In particular, it is possible to do immediate-mode style rendering if your server extension fully supports the PEX protocol and you have some way of generating these protocol packets. In particular, the idea of using a ``Renderer'' (instead of a PHIGS workstation) resource covers this idea. Jan Hardenbergh of Stardent has been working on a proposed API interface to this portion of the protocol (the API is collectively called PEXIM for PEX Immediate Mode). In client land, the protocol is generated by the API. It doesn't matter if your API looks like the QuickDraw, PostScript, SGI's GL, or whatever. The server is *still* going to interpret those protocol requests according to PHIGS/PHIGS+ functionality and semantics. If it doesn't, then its not PEX, but some homebrew 3D extension to X. Given this preliminary explanation of how I am using these terms, Greg says: >However, it is an extension to the core X protocol. It simply relates >specific byte encodings to specific server actions on the part of the >PEX extended server. It just so happens that PEX was designed >specifically to support the functionality that PHIGS and PHIGS PLUS >offer, but it is not an Application Programming Interface. Correct. The PEX protocol is not an API, but PEX as distributed by the SI does include an API based on the DIS C binding for PHIGS/PHIGS-PLUS. I think we're just quibbling about what is meant when one says "PEX". I take it to mean both the client-side API that generates the protocol requests and the server-side extensions that implement the requests. So far, I've not seen a special name for the client-side portion. >Saying PEX uses PHIGS is like saying X uses XView or the Athena >Widgets. See above. Given that PEX implements the functionality and semantics of PHIGS, I believe it is correct to say that PEX uses PHIGS. Again, it doesn't matter what API you have, the rendering is still done according to PHIGS functionality and semantics specifications. From documents originating with the PEX architecture team and SI team, this has always been clear to me. >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). -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer