Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!purdue!haven.umd.edu!ni.umd.edu!sayshell.umd.edu!louie
From: louie@sayshell.umd.edu (Louis A. Mamakos)
Newsgroups: comp.sys.next
Subject: Re: Postscript
Message-ID: <1991Apr24.150511.10964@ni.umd.edu>
Date: 24 Apr 91 15:05:11 GMT
References: <1991Apr22.212326.26982@csusac.csus.edu> <1991Apr22.211904.8832@ni.umd.edu> <47755@ut-emx.uucp>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: University of Maryland, College Park
Lines: 71

In article <47755@ut-emx.uucp> mic@ut-emx.uucp (Mic Kaczmarczik) writes:
>	I may be missing the point here, but for the Distillery, could you
>	maybe use the pft program to communicate with your server, and have
>	the distill program write the distilled code to the standard
>	PostScript output?  This should be pretty similar to talking to a
>	LaserWriter over a serial line.  I have not tried it, but something
>	like
>		cat still.ps myfile.ps | pft >myfile-distilled.ps
>
>	might at least let you use the Distillery.

I've actually tried to do this under Release 2.0, but there are some sort of
buffering problems with pft such that the last bit of the output is truncated.

I have not tried it again under Release 2.1 to see if that pft related
problem is fixed or not.

>	However, perhaps at least locally, Mach port-based
>	authentication could be used to figure out the uid/gid to use for
>	*some* class of file opens.  That way, if you open an authenticated
>	connection to the PostScript server, you can have the server open
>	files with your access rights.  I share your hope that this will
>	be fixed in a later release (the sooner the better).

An arrangment like this sounds like it might work just fine.  So long
as some *reasonable* solution is found to the problem, I'll be happy.
But just disabling a working capability with no advance warning from a
vendor is not a resonable solution.  And that's the point I was trying
to make.

In the "old days", our mainframe vendors would give advance notice on
the order of 6 months to a year of software and capabilities that they
were intending to no longer support, as well as migration tools when
appropriate.  This gave customers with production applications time to
transition their production applications before the operating system
features that they depended upon disappeared.  There was no pulling
the rug out from under the customer.  There was also continuing
support of older versions of the system software for some period of
time as well.  If you didn't want to move to the latest and greatest,
you could continue to use the "old" stuff.

What do you think NeXT would do if you reported a bug in Release 1.0?
They'd laugh at you and tell you to use 2.0 or 2.1 since that's the
"supported" version of software.  My point here is you can't have it
both ways; either

	* you tell your customers ahead of time what to expect
	in future releases if you're only going to support the current
	release, or 

	* you support multiple versions of software.

How else can I build serious applications if I can't depend on
capabilities and features?  Is this a "real" computer or not?  I got
no response to the bug report that I submitted on this when Release
2.0 first came out either.

In my case, I was depending upon this feature to take Adobe
Illustrator files from a Macintosh which are replicas of the various
forms that we use at the University (purchase orders, etc).  We have a
print queue in our network printing system that can merge the
PostScript for the form with the ASCII text from our Large IBM system
things on the TCP/IP campus network, and prints them on printers
around campus.  We can save pile 'o money by not needing pre-printed
forms.

We chose to use a NeXT platform because it is such a wonderful beast
to do PostScript development on.  Now I can't use it for that function
as I was before.  Thanks, guys.

louie