🚀 go-pugleaf

In article <5681@m1.cs.man.ac.uk>, lilleyc@cs.man.ac.uk (Chris Lilley) writes:

|> How does one find which of the three subsets a given PEX server
|> supports? I am looking for a short program to tell me. Also, how to
|> tell if a server is 5.0 or 5.1

The PEX Request PEXGetExtensionInfo will return this information.
A short PEXlib program can be written to query and display this information.
I have also heard about a program called pexdpyinfo, which works a lot like
xdpyinfo except that it returns the same info provided by PEXGetExtensionInfo
plus perhaps the ImpDep Constants and EnumTypes.  I do not know the
status of the program.  However, a program to print just the return info 
from PEXGetExtensionInfo is pretty simple.

|> Reason I ask: we have a VAXstation here running PEX. It displays DEC
|> phiga apps to either an X or a PEX workstation (ie workststion types
|> 231 or 241, for Motif).  As far as DEC PHIGS is concerned, PEX is
|> there and able to support server-side structures (that is, indeed, the
|> default). DEC PHIGS generates PEX 5.0 protocol.
|> 
|> We recently tried to display output from SunPHIGS 2.0 which claims to
|> support PEX when present. This failed with an error message which
|> apparently means that the PHIGS workstation subset is not present.

SunPHIGS apparently requires the Workstation subset.  DEC PEX servers
generally do not have the workstation subset.  (Before criticizing, see
below)
SunPHIGS, by the way, runs pretty well to other PEX servers that do support
the Workstation Subset.  For example, at SIGGRAPH this year, I was
consistently displaying several SunPHIGS clients (running on Sun machines)
to our IBM PEX server.  

|> A demo program which came with a Tektronix XP29P PEX terminal we are
|> looking at also failed with the same error. This program supports 5.1
|> protocol.

Failed when running to the DEC server?  If it is a PHIGS program (maybe
written to the SI-PHIGS), then the missing Workstation subset is the
cause again.

|> Could someone give me a quick summary or low-down on PEX subsets, how
|> to get around the above problem and (preferably) why PEX has three
|> subsets. Is this not going to be a bit of a problem in the future?

Yes, it is and will be a problem.  For this reason, there is considerable
interest in 'no subsets' for PEX 6.0.  
The future of the Workstation Object/Subset is in doubt also.

I don't think I was involved much with PEX when 5.0 was started, but
I guess that the existence of the Workstation was a controversial issue.

Some say that the Workstation function was needed to implement an
efficient PHIGS and that the extra 'policy' imposed by the PEX Workstation
functions was not a problem, from an 'X' point of view.

Others argue that you can implement PHIGS without the Workstation functions
and that the policy imposed by the current Workstation functions
was too much, as compared to the rest of X.

Some vendors, like DEC I guess, had implemented PHIGS without a
Workstation object before PEX 5 came along, so they saw no reason to
add it.  Other vendors may also have objected strongly to being forced
to implement ALL of PEX when they had real disagreements over some of
the function.

Rather than let programs die by sending unimplemented PEX requests,
the subset bits were added so a client can at least find out what is there.

How to get around it?
Well, for now, if you want your client to run on every PEX server,
you have to check the subset flags and make your client program adjust
accordingly.  With the current subsets, you have to be able to handle
7 different configurations.

|> Also could someone give me the email address of the PEX
|> interoperability centre as I have some other stuff I would like to
|> share with them.

pexic-pub-tech@convex.com


Karl Schultz                             schultz@vnet.ibm.com
These statements or opinions are not necessarily those of IBM