Here's a deeper discussion of the technical design differences between NeWS and Display PostScript, from a discussion with Robin Schaufler and James Gosling:
From: James Gosling <jag@Sun.COM>
Subject: Re: Display PS vs NeWS
Date: 22 December 1988 at 19:35:08 GMT+1
To: Robin Schaufler <robin@Sun.COM>
Cc: don@brillig.umd.edu (Don Hopkins), sevans%norquay@Sun.COM
Robin: Don, I'm replying just to you, not to NeWS-makers (trying to stay out of
trouble). The one major area where NeWS cannot emulate Display PS is that of
memory management. Display PS introduces the notion of spaces; effectively,
each process group gets its own heap. Kill the process group - the memory gets
cleaned up whether it has cycles in it or not. Very nice, actually. But a
major project for us if we decide to adopt it. Fortunately, we already started
on a new memory management system for data localization that will help some
with implementation.
James: The thing that we don't have is a thousand caveats on what can be
assigned to what. You can't have pointers that cross spaces in Adobe's
scheme, so as you read through their documentation you find zillions of
restrictions that make life very difficult. Also, the "kill the
process group..." doesn't really apply: they don't have process
groups. Each process is alone. If you want to share, you have to
stick stuff in the "shared" space or be forked from a common parent.
save/restore has bizarre semantics in this memory model: eg. if a
process executes "save" then any other process that shares the same
storage pool is blocked (honest, I'm not making this up!)
Robin: We also can't emulate their lock mechanism. I had the distinct impression that
they analysed NeWS monitors completely, figured out exactly what was wrong with
them, and fixed it. I really like this extension, but again, considerable work
for us (tho less than for the memory management extension).
James: Far from considerable work and of dubious value: almost no one has ever
used locks. DPS locks are identical to NeWS monitors (they're even
applied with the same primitive "monitor"). NeWS is missing condition
variables, which are a good idea but not difficult to implement. Events
are the common form of process syncronization in NeWS.
Robin: Another area we would have trouble emulating is their new halftoning operators,
but that seems like less of a problem. The new operators allow for tiling,
which we've implemented for X, but we'd still have to hook it up for NeWS,
and provide their model, which isn't quite the same model. Actually,
NeWS probably can emulate it but it would be beastly slow.
James: Actually, the DPS threshhold are NOT the tiling operators that
PostScript so badly needs. If you read it carefully, for devices with
more than one bit per pixel you can't get the tiling effect. Halftones
continue to only be useful for halftoning.
Robin: In a few cases they picked the same names and operator spec as us, but in
general they didn't try to be compatible. A few incompatibilities seem
gratuitious to me.
James: eg. processes
James: The thing that we don't have is a thousand caveats on what can be assigned to what. You can't have pointers that cross spaces in Adobe's scheme, so as you read through their documentation you find zillions of restrictions that make life very difficult. Also, the "kill the process group..." doesn't really apply: they don't have process groups. Each process is alone. If you want to share, you have to stick stuff in the "shared" space or be forked from a common parent. save/restore has bizarre semantics in this memory model: eg. if a process executes "save" then any other process that shares the same storage pool is blocked (honest, I'm not making this up!)
Robin: We also can't emulate their lock mechanism. I had the distinct impression that they analysed NeWS monitors completely, figured out exactly what was wrong with them, and fixed it. I really like this extension, but again, considerable work for us (tho less than for the memory management extension).
James: Far from considerable work and of dubious value: almost no one has ever used locks. DPS locks are identical to NeWS monitors (they're even applied with the same primitive "monitor"). NeWS is missing condition variables, which are a good idea but not difficult to implement. Events are the common form of process syncronization in NeWS.
Robin: Another area we would have trouble emulating is their new halftoning operators, but that seems like less of a problem. The new operators allow for tiling, which we've implemented for X, but we'd still have to hook it up for NeWS, and provide their model, which isn't quite the same model. Actually, NeWS probably can emulate it but it would be beastly slow.
James: Actually, the DPS threshhold are NOT the tiling operators that PostScript so badly needs. If you read it carefully, for devices with more than one bit per pixel you can't get the tiling effect. Halftones continue to only be useful for halftoning.
Robin: In a few cases they picked the same names and operator spec as us, but in general they didn't try to be compatible. A few incompatibilities seem gratuitious to me.
James: eg. processes