🚀 go-pugleaf

In article <1992Dec14.173431.16745@dsd.es.com> rthomson@dsd.es.com
(Rich Thomson) writes:

>In article <1992Dec9.155020.19988@mintaka.lcs.mit.edu>
>	mor@xenon.lcs.mit.edu (Ralph Mor) writes:

> >In DEC PHIGS, the default workstation (specified by phigs$wstype and
> >phigs$conid environment variables) is opened at OPEN PHIGS time.

This is clearly an optimisation on DECs part - they open a workstation
then put the structure store there. Chances are, if that is the
workstation type you have set up as your default, that is the one you
are going to open. If not, the CSS is copied accross to the new w/s.
Regardless of this practical optimisation, conceptually there is no
open workstation at this point.

>OK, but what does this have to do with the list of workstations that
>are supported by the connection?  The connection is still made at OPEN
>PHIGS time, right?  

Wrong, sorry. (Really, Rich, you should know better!)

OPEN PHIGS
Parameters:
	in	error file
	in	amount of memory units for buffer area

OPEN WORKSTATION
Parameters:
	in	workstation identifier
	in	connection identifier
	in	workstation type

>When you connect to a PHIGS implementation it
>should know what kinds of workstations are supported.

Yes, it has a list of possibly a hundred PHIGS workststion types
supported by that implementation. (DEC PHIGS, for example, lists 65
workstation types). You seem to be confusing the implementation with
the connection, not formed until a particular workstation type has
been selected and a connection made to an instance of that type with
the open workstation call. Open PHIGS starts you talking to the
implementation as a whole, not a specific workstation.

> >The point is that OPEN WORKSTATION can open a workstation that is
> >not the default.  So, INQUIRE WORKSTATION TYPES (which can be called
> >before OPEN WORKSTATION), does not know ahead of time if there will
> >be a connection to a valid PEX display.

>I don't see how "default workstations" should change INQUIRE
>WORKSTATION TYPES.  

It doesn't. The _implementation_ supports various PEX workstation
types. So if you ask does support say an OSF/Motif drawable, or a
Tektronix 4129, or a colour EPS file it will say yes. (Well, DEC PHIGS
will anyway, as that is the example under discussion). If you then go
opening, say, an OSF/Motif PEX I/O workstation, and the ip address
doesn't have an  X server somewhere, or that server does not have the
PEX extension, your open workstation call will generate an error. The
implementation can only ask a particular X server about it's
extensions if it knows which machine,server and display to ask
(specified by the connection identifier). X being network transparent
and all, the server on your local machine might not be the one you
want to connect to.
 
>Or are you saying that the connection to the PEX
>server isn't made until OPEN WORKSTATION time?  That doesn't sound
>very smart.

You may not think it smart, but that is what the standard says - the
connection is formed by the OPEN PHIGS call. And if you wanted to
design an implementation that deviated from the standard, what would
you use as a connection id? Which server would you connect to?

Bear in mind that PHIGS is not exclusively a way of drawing on X
window screens; there are a wide variety of possible workstation types
from old tektronics terminals at the end of slow serial lines, to
various other non-X displays, or hardcopy devices, or even files. The
program might be writing to an EPS file, or an HPGL file. Heck, it
might even never open a workstation at all! It might do a bunch of
number crunching, possibly in the background, write out an archive
file, and quit. To quote the PHIGS standard (section 4.3.2))

"PHIGS is not restricted to graphics and provides data structure
definition and editing facilities which are not necessarily related to
graphical output."

Why would an implementation  go connecting to a (random?) PEX server
under those circumstances?

I guess the bottom line is that, although this is being discussed in
the PEX group, PHIGS is not just PEX. Of course, if you are a PEX
programmer this fact might slip from your awareness a bit.


--
Chris Lilley
---------------------------------------------------------------------------
Technical Author, ITTI Computer Graphics and Visualisation Training Project
Computer Graphics Unit, Manchester Computing Centre, Manchester, UK
Internet:   lilley@cgu.mcc.ac.uk        Janet:   lilley@uk.ac.mcc.cgu
Voice:      +44 (0)61 275 6095          Fax:     +44 (0)61 275 6040
---------------------------------------------------------------------------