NeWS was not actually Adobe's Display PostScript, but it was Sun's independent implementation and specialized dialect of PostScript, supporting light weight processes, overlapping arbitrarily shaped canvases, window management, event distribution, garbage collection, networking, object oriented programming, etc.
The most important ability that NeWS had, but was missing from Display PostScript and its successors (OS/X Core Graphics, PDF, SVG, canvas API, etc), is the ability to download code to create an efficient custom high level application specific protocol between the client and server.
That essential ability is what people call "AJAX" these days, now that PostScript has been supplanted by JavaScript and a whole bunch of different APIs, and now we're even downloading shaders to the GPU! Truly exciting!
James Gosling chose PostScript from the start, for how its network programming ability dovetails with its graphics and data representation, instead of nailing it onto the side of a bunch of different technologies as an afterthought.
To quote the comparison from the wikipedia article:
NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:
1) used PostScript code instead of JavaScript for programming.
2) used PostScript graphics instead of DHTML and CSS for rendering.
3) used PostScript data instead of XML and JSON for data representation.
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.
The most important ability that NeWS had, but was missing from Display PostScript and its successors (OS/X Core Graphics, PDF, SVG, canvas API, etc), is the ability to download code to create an efficient custom high level application specific protocol between the client and server.
That essential ability is what people call "AJAX" these days, now that PostScript has been supplanted by JavaScript and a whole bunch of different APIs, and now we're even downloading shaders to the GPU! Truly exciting!
James Gosling chose PostScript from the start, for how its network programming ability dovetails with its graphics and data representation, instead of nailing it onto the side of a bunch of different technologies as an afterthought.
To quote the comparison from the wikipedia article:
NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:
1) used PostScript code instead of JavaScript for programming.
2) used PostScript graphics instead of DHTML and CSS for rendering.
3) used PostScript data instead of XML and JSON for data representation.