It is under 20K lines of C, and very easy to port. It is able to run over a serial line or a socket, in a few hundred K of RAM.
Screenshot: http://www.hack.org/mc/mgr/images/mgrscreen.png
More info: http://www.hack.org/mc/mgr/
"MGR is to X as Unix is to Multix." -Dan Nachbar
Some neat ideas. Nice and minimalist.
"MGR notifies a client program of an event by sending it an ASCII character string in a format specified by the client program."
It sucks that VNC, X11, and RDP are the best we have... though, I will admit RDP is pretty serviceable, X11 just seems too janky to work over a really remote connection... and VNC, well it works, but, sigh...
I don't think that any remote application UI will really take over as everyone that might work on such a thing wants to gain a lock in with the goal of financial gain... so nothing really reaches a significant market share. This is the case were something that is great and libre/opensource would be better than a standard.
Surely It is.
But I cannot forget how magic it seemed in the 80s doing
titan$ export DISPLAY=zeus:0.0; xeyes &
zeus$ xhost +
;)
My favorite OpenWindows demo was Pat Lashley's monaeyes [4], of course. And I made a fancy version of eyeball windows for The NeWS Toolkit [5] to show off its drag-n-drop and nested window management capabilities, where the eyeball was the window frame, and the iris was the client window, and you could split them in two, and even drag and drop eyes inside of each other, so that sub-eye window frame was reparented inside the moving super-eye client iris! The effect was very creepy and CPU intensive, and I could never quite talk the OPEN LOOK folks into adopting them into the standard.
[1] http://donhopkins.com/home/archive/news-tape/fun/eye/eye.ps.txt
[2] http://www.x.org/archive/X11R7.5/doc/man/man1/xeyes.1.html
[3] http://donhopkins.com/home/archive/news-tape/fun/melt/melt.ps.txt
I mean, the web is great for a lot of stuff (as I said)... but I feel it is a shame that we don't have a modern alternative for client/server applications... and every time I see one that has a lot of potential, it usually has some strings that will prevent adoption.
• Encryption can be completely disabled, forcing plaintext login – to comply with French government orders at some point in the 90s. It's still implemented in a lot of clients, because why not?
• Serial and parallel port forwarding (suddenly, USB over JS doesn't seem that surprising any more…)
• SMB share forwarding (complete with 8-byte-name-limit)
• SMB printer forwarding (as opposed to parallel port printer forwarding). rdesktop's manpage helpfully states that "Keep in mind that you need a 100% match in the server environment, or the driver will fail." Charming!
• PCI device forwarding. Holy mother of DMA attacks!
You know, WebRTC doesn't seem too bad…
Could you give me a citation for this please? Google is unhelpful and only refers to "PCI compliance" which is not at all the same thing (and also a problem for different reasons).
RDP and VNC are immune to this because they are just glorified animated gif streams, but NeWS would be prone to the same problem if it was alive today.
CADT at work yet again it seems, as it the code could iterate faster if they were not bound by having the OGL traffic go through the X infrastructure.
From there is has been a hop skip to Wayland, where X is seen as a slowly withering appendage.
That's not correct. If DEs actually were using OpenGL for UI acceleration, then at least for GL-2.1 and earlier everything would be sent as pure drawing commands to the display server by means of the X11/GLX transport protocol (indirect rendering context).
What actually happened was, that for some reason the developers of the toolkits thought, that it was somehow necessary to render everything in the client into a pixmap and only as a last step pass this through the X11 to the graphics hardware, thereby degrading the X11 server to a glorified bit-blitting machine.
That's why the design of Wayland is how it is, because toolkits developers couldn't be bothered to actually using the X11 drawing primitives in a clever way. And if you're not a total moron you can make it look extremely good. One thing that I never understood is, why antialiasing was never enabled for X core drawing primitives; it's not like you couldn't use raster ops with antialiased geometry either (like the XOR overdraw method).
Then again i have found the whole compositor thing unreliable at best. I still have it turned off on my (aging) XFCE install.
Anyways, i think the primary reason they want X11 dead is the whole security thing.
It seems there is not a week going by without some blog or other warning about how anything can sniff and/or insert keystrokes in X11, never mind screen scraping, and how Wayland will fix all that.
Never mind that one man's security issue is another man's feature...
That's not how it works. KMS is something display servers (X11, Wayland compositor) use, not something a client application should or would use (too impractical.
DRI only comes into play if you're creating a direct OpenGL context running one of the open source OpenGL drivers (Mesa + DRM).
It does nothing for regular X11 clients, that don't use OpenGL. Actually DRI does not do drawing at all, it's mostly just a way for bypassing the X11 server for direct OpenGL contexts as specified in the GLX specification. Essentially it's shared memory plus mmaping certain regions of the video device into clients' address spaces.
You can't draw shit using DRI.
Again: This neither KMS, nor DRI/DRM, nor OpenGL have anything to do with the braindeadness of "modern" X11 toolkits.
What does have something to do with it is reinventing the wheel and to all the rasterization work in software client side in code contained in the toolkit (Cairo in the case of GTK+, "raster" in the case of Qt). Why these custom rasterization engines have been implemented?
Well, mostly to be able to use the toolkits in an embedded environment that lacks a display server with drawing primitives (for example DirectFB). Eventually the scope expanded to draw single widgets for X11 and at some point it was decided that it would be easier to just render the whole thing in software and then blit.
People were dissatisfied with the graphics primitives offered by X11 / XRender. Yes, I admit, rectangles, triangles, polygons, lines, arcs and ellipses are not that much (/s); there's still the desire for Bezier curves. And yes, I admit that the X11 graphics model may be somewhat limiting when it comes to composing drawing layers, as you need it for, say CSS.
However I consider it mostly a lack of creativity and determination. XRender can be quite powerful if you know how to use it. And with Glamor at last it will be GPU accelerated.
But once we got things like Compiz, a major shift in attitude towards X11 came about.
What the…? Are you trying to pull a "Hey, look over there, a three-headed monkey!"?! Why are you now pulling Compiz into the argument? It's totally irrelevant for this discussion.
Compiz is just a client that makes use of a concerted effort of the XRender, the Composite and the AIGLX extensions to composite whole windows to the screen. AIGLX is an acronym for "Accelerated Indirect GLX"; don't ask why that acroynm was chosen, because GLX itself already is accelerated and may be indirect.
Compositing also doesn't care about how you draw to a X11 drawable. All it cares about is: Here is a set of X11 drawables (windows, pixmaps), all server side, which you can draw to with server side accelerated rendering primitives. And then over there's a compositing surface (the composite layer window). The X11 server then is: "Now please give me drawing instructions on how to get the composite surface filled with the contents of the drawables!"
The compositing effects render completely server side, even if OpenGL graphics effects are used, thanks to indirect rendering command execution (heck, you can even compile the drawing commands in a display list (an ooold OpenGL feature; so old, it's been removed from modern OpenGL versions) and have the whole thing executed by sending a single glCallLists command to the X11 server via GLX).
There is a deep-down irreconcilable philosophical and mathematical difference between X11's discrete half-open pixel-oriented rendering model, and PostScript's continuous stencil/paint Porter/Duff imaging model.
X11 graphics round differently when filling and stroking, define strokes in terms of square pixels instead of fills with arbitrary coordinate transformations, and is all about "half open" pixels with gravity to the right and down, not the pixel coverage of geometric region, which is how anti-aliasing is defined.
X11 is rasterops on wheels. It turned out that not many application developers enjoyed thinking about pixels and coordinates the X11 way, displays don't always have square pixels, the hardware (cough Microvax framebuffer) that supports rasterops efficiently is long obsolete, rendering was precisely defined in a way that didn't allow any wiggle room for hardware optimizations, and developers would rather use higher level stencil/paint and scalable graphics, now that computers are fast enough to support it.
I tried describing the problem in the Unix-Haters X-Windows Disaster chapter [1]:
A task as simple as filing and stroking shapes is quite complicated because of X's bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra "bonus pixels" when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that "in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion)." This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can't even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses even though you scaled the rectangle corner coordinates to compensate for the aspect ratio.
[1] The X-Windows Disaster: http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html
If adding graphics primitives via X extensions worked as advertised, then X would have solved all these problems we're still having decades ago.
But as the HP technical support person said, "Why would you ever need to point to something that you've drawn in 3D?"
Indeed. But we're not talking about this. We're talking about the faux reasons why X11 toolkits started doing client-side rasterization (which is still pixel oriented), instead of doing just a little bit of work, making X-core primitives beautiful for framebuffers configured the right way.
> A task as simple as filing and stroking shapes is quite complicated because of X's bizarre pixel-oriented imaging rules.
Here's the thing: When XRender was added, it introduced a whole new set of framebuffer configuration options. It is these options that allow one to specify antialiasing modes and it's the very same options that also have to be used if one want to use OpenGL multisample antialiasing on a window facing framebuffer (without a multisampled window format the only way to get MSAA with OpenGL is to create a multisampled OpenGL framebuffer object render-target and perform multisampling resolution via framebuffer blitting).
The point is: It would have been trivial and perfectly allowed to alter the rasterization specification for X core drawing primitives in case a multisampled framebuffer configuration was active for the window. Replacing drawing behavior is something perfectly normal when introducing new OpenGL features (either by new version or extension) and the very same would have worked just as fine for X core.
if( fbconfig.multisampled ) {
draw_Xcore_primitives_with_new_antialiased_rules(...);
} else {
draw_Xcore_primitives_with_traditional_rules(...);
}
Note that if you want to replace X11 with something sensible, you're preaching to the choir. I've been advocating the use of abstract display systems, that are graphics primitive oriented (instead of pixel oriented) for years (actually over a decade now). But I've also found that many proponents and opponents of X11/Wayland/etc. do not actually understand the problem at all.
All of that beautiful free open source rendering code was originally conceived in the master bedroom of its parent's house, the X11 server. Its parents had ambitious but traditional plans for it, from the time it was only one bit deep, and as it grew up and learned how to walk around on eight bits with the help of a colormap.
Then when it finally reached puberty and learned how to composite 24 bit images into deep visuals, it needed more space and some privacy of its own, and room to store its growing collection of pixels, so its parents moved it into the X Rendering extension in the basement.
But it still had to share a single telephone line with its parents, who monitored all of its communications and screened its friends, while insisting it do all its chores like taking out the garbage and cleaning its buffers, before going out and playing with its friends.
It managed to open up a shared memory window into the back yard, so it could move larger quantities of pixels and cache back and forth between its local clients and its room in the basement, without waking up its parents in the middle of the night.
But as it grew up, it started dealing more and more little packets of pixels with its local clients on the side, and going away on frequent rides to make deliveries to remote clients, so its parents became suspicious and angry.
This caused many problems, but managed to work for a while. But then when it got older, it started getting invited to sleep over parties, where its friends and growing list of clients invited it to bring all its favorite pixels to their house to share and mix together.
Eventually it was regularly performing as Master Compositor at huge parties, pumping out colorful house pixels with throbbing techno alpha channels, deep into the night and on into the early morning.
But that behavior caused terrible problems with its parents at home, who didn't approve of being out of the loop, but still having to foot the bill for its Frosted Flakes and AOL subscription.
Finally it got its shit together enough to move out of its parent's basement, and into a small shared library apartment in Cairo, so it could perform freelance jobs for its growing list of clients who didn't want any involvement with its parents. Now it could party with its friends and clients, without its parents knowing and interfering with its pursuit of happiness.
Its parents had some very old-fashioned parochial ideas about font rendering and naming. They firmly believed that a font's place was in the pixmap, angrily hated the ideas of mixed alpha antialiasing or same alpha transparency, approved of the missionary transform but were otherwise affine-transphobic, and they sternly disapproved of outline fonts with soft voluptuous curves and gentle antialiased edges.
But with its new found maturity and hard earned freedom, it got lucky enough to hook up with a sexy outline font rendering stripper named Crystal FreeType and an elegant internationally suave text layout pole dancer named Paris Pango. As a free software threesome, together they integrated seamlessly, worked beautifully, hooked up with prolific scripts and toolkits, and painted some truly epic scenes.
As their careers advanced, they were employed in many important high profile jobs, including as Art Director of the renowned GTK+ Disco Dance Party (the Soul Train of the Desktop, syndicated to a long list of platforms and scripting languages), and MC (Master Compositor) of the internationally televised Mozilla Firefox Web Surfing Variety Show (based on the original Solid Gold Netscape show, that inspired all the others).
Not only did they cover other famous artist's works like HTML, CSS, SVG, PDF and XUL, but they also showcased their own instant-classic Canvas API, which revolutionized the world wide web and matured from a popular fad into an essential institution used by everyone around the world.
So at this point in history, there's really no point in asking such successful code to go back and live in its parent's basement again, because its style would be cramped, and nobody would want to visit it there, now that it finally has its own rich interesting life to live in the real world. ;)
But like all stories, also this one has a twist for the dark: Although the art created by the protagonist was of high quality, the artists technique was behind the curve of what people actually wanted to see. The sad thins is, people didn't exactly know what the wanted to see, unless it was shown to them. Also our protagonist artist had a obsessive preference for his drawing substrates: The only canvases he'd be drawing on would consist of orthogonal grids and would only fill each cell with a solid color. His sidekick Crystal Freetype was okay with it, but also figured, that some people, for some reason liked it, if she tripled the resolution of the grid in one direction and biased the hues by a periodic red-green-blue pattern. But she never got really perfect at it.
Some say, and those would clearly be right, that the reason for that was, that the people who'd wanted to see their art would do it only at galleries: But those galleries had problems with reproducing their illumination. Each gallery had slightly different light. For a long time each gallery tried to compensate with its own tools, documenting what had to be done in a customary way. Eventually all these galleries got their act together and agreed on a specific way to tell each other and the artist how the light looks at their place.
They also realized that for maximum effect the light at the gallery had to be taken into account when drawing the pictures.
Unfortunately our hero "rendering code" never properly learnt what to make out of the information he got from the gallieries. He preferred to work with his preferred colours Red, Green and Blue and knew how to mix them according to the color theory on RGB colors "s" as laid down by his idol "Adobe" (also called sRGB), but Crystal FreeType never got the knack for it, messing up the Gamma of her antialiasing. There would have been of course the color theory of linear contact color spaces, but our hero abhorred the idea to work with "imaginary" colors, or that the dyes in his paints would only look right after being treated with a colorspace-converting developer.
Sometimes two galleries would want to exhibit the same picture. Or one gallery one part and another gallery the other part; or maybe three or four libraries. Of course our hero could have carefully planned how to draw each part of his paintings, but this would take time and more importantly much more extra effort in dealing with his clients. So instead most of the time he'd just draw for the lowest common denominator. The pictures would be not as pretty as they could have been, but at least everybody got to see something.
But what really dragged down our hero was, that his paintings were heavy. Moving them around in towns where his clients lived already was hard work, but it was manageable, thanks to the heavy dutry transport system available. But sometimes a gallery away from his clients wanted to show the pictures and then it got really messy.
Some clients remembered that when "hero rendering code" still lived at his parents, he could give his parents a call and place an order for a picture to be drawn. He'd just telephone what it should look like, which went rather quickly. Of course some clients adopted a inefficient way of placing their orders, stating one item, asking if it was on the list then asking for the next one, and so on. Other clients became clever and just placed their whole order before asking back; often "hero rendering code" would already be at work, when the confirmation on the order arrived. Of course there would have still be problem of moving the picture to a gallery… but as it turns out the parents had a huge library with reconfigurable walls at their house. So clients who'd just want to show drawings drawn by "hero render code" at his parents libraries according to their telephone calls could do this from practically everywhere, even over telephone lines that could barely carry a conversation, yet patrons would see the same image quality.
But now with "hero rendering code" insisting on doing his work in the clients town transporting the pictures became a major issue. Some clients found the services of the Shrinker Codec Union; their union workers would deconstruct the drawings of "hero rendering code", sweep things under the rug they's presume the patrons would never see and transport that. For very complicated images they figured out, that this was actually faster than trying to talk the complicated picture through the telephone line; yet the price was, that pictures often suffered in their colour brilliance. It was however Crystal FreeType who's be extremely outraged, because it was often her expertly crafted contributions which got mauled by the Shrinker Coded Union workers.
Meanwhile new drawing tools appeared on the market; or rather they've been on the market for quite some time, but hero rendering code never learnt how to peoperly use them. His parents added an annex to their house though where those drawing tools could be used. But often it were hero rendering codes clients who'd then use these tools for their own means. Hero rendering code often tried to get to grip with those tools but often failed miserably; maybe hell never learn. And Crystal FreeType, she doesn't even understand how to use these tools properly; FreeType lais out her pictures and spans of lines, she'd colour in particular colors. But those new tools, if they are used like that produce poor results or it takes much longer to get a nice picture of a character, than using the old tools. But it's not that this is impossible. New artists who are expert in the use of these new tools have become runners up.
But many of hero rendering code's clients are now so closely tied to him, that they can't make use of those new expert drawers services. And they remember the times, when they could give the parent's "X11" a house call and have them write down the order for the picture.
Wouldn't it maybe be possible to create a lodging home and gallery for all these new artists in town, where one could place house calls for showing their drawings on premises? In a Gallery where the artists can paint the interesting parts of their painting in the room where they're going to be shown, matched to the lighting conditions then and there? Without the need to haul havy paintings over land?
to be continued…
"Sam is implemented as two processes connected by a low-bandwidth stream, one process handling the display and the other the editing algorithms. Therefore it can run with the display process in a bitmap terminal and the editor on a local host, with both processes on a bitmap-equipped host, or with the display process in the terminal and the editor in a remote host. By suppressing the display process, it can even run without a bitmap terminal."
Aye, and there's the rub.
"I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I’d like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things)." -http://www.thelinuxdaily.com/2010/04/the-first-linux-announcement-from-linus-torvalds/
I used, every single day, a product called "FastX" from StarNet, that runs X over RDP. It means the X programs I display on my Mac (which are running on a Linux box) are disconnectable/reconnectable. I disconnect when I'm ready to go to work, reconnect there, and do the same thing when I finish at the end of the day.
Absolutely lovely.
That hasn't been the case in my experience.. thanks for the heads up though. I tried NoMachine's NX for a while, which was very nice.
You could do some neat tricks - draw something in the graphical editor, copy it and paste it as the shape of a window (stack). Another thing you could do was log in through the PostScript shell to the server, navigate to your window (or anything else) and fiddle with it using standard PostScript 2D transforms. e.g. You could gradually rotate a terminal window, although I would never have done this to a colleague as they were using it, honest.
I rather enjoyed working in PostScript although I believe there was a C to PostScript compiler built at one point (inevitably this being done in Glasgow it was called pdb for "pure dead brilliant").
Don't think there was much of a security model in NeWS so probably not a great fit for today's world but it was so much cooler than X.
The model was really cool - completely different from X11, which is much more limited. With X, your app runs on the client and sends drawing commands to the display server. With NeWS, you can split your app arbitrarily between the client and the display server. The client simply extends the server by sending it postscript functions to locally interpret when asynchronous events happen. So you can write new widgets, and they run entirely on the display server so get really low latency, while the rest of the app is running remotely over a piece-of-wet-string network connection.
You could be sitting in from of a display running a nice interactive GUI, with the app running in a different country or over a modem connection. At least you could if the application designer got it right. Getting the split of functionality between the client and server (and the communication between them) right was definitely more challenging than writing X apps, but the benefits were significant.
http://sydney.edu.au/engineering/it/~matty/9term/
https://github.com/chneukirchen/tt
The original Plan 9 terminal and window manager are described here:
I get the feel it was the aim of Netscape from the virtually the beginning.
After all, the browser war was a proxy war for the server market and the intranet concept. As in using internet technology for the corporate LAN, with the web as the GUI for corporate servers.
Also, it had PizzaTool. http://www.donhopkins.com/home/catalog/images/pizzatool.gif
Source code: http://www.donhopkins.com/home/code/pizzatool.ps.txt
I've always rather wondered why no open source NeWS clone never came along.
[Edit: I was pleasantly surprised at how readable that code is]
...but I saw it running in real time, and it was actually pretty cool to see all the toppings appear (this was on a Sparc ELC-class machine, so it didn't have much grunt). Seamless dithering on the monochrome display, too.
Also, the spinning the pizza was done by rotating the rendered bitmap. The inaccuracies meant that as you spun it, the toppings would all gradually blend into each other. I suppose that's realistic, in a way.
You're right, that was the best "melting" effect I could come up with, within the constraints of the PostScript imaging model. PizzaTool spins the pizza automatically, because I got tired of turning the image rotate tool in Stuart Marks' RasterRap by hand again and again to get that melting effect. I left it running over Christmas vacation, and it collapsed into an blob. But you can still add more toppings at any time while it's spinning!
Here's a demo of spinning pizzas, dragging and dropping images between RasterRap and PizzaTool, and cleaning the pizza tray afterwards with a wave. Sorry about the bad video quality!
https://www.youtube.com/watch?v=avJnpDKHxPY&feature=youtu.be&t=21m42s
What was the NeWS security model like? Could it safely combine Postscript programs from multiple users on the same display server without information leakage between users?
And I suppose the NeWS source code got eaten by lawyers long ago and is unlikely ever to see the light of day?
Tools that imported EPS could be tricked into doing all kinds of stuff like forking Unix processes, and open files. And being able to open files also meant opening sockets with the %socket syntax.
NeWSPrint was a laser printer that ran NeWS on a workstation to render pages, in a stripped down presumably firewalled environment. But I was able to cause an error in a certain context that left an execution stack dump on the operand stack before calling my code, and inside that stack dump were nested executable arrays of PostScript code that contained an inlined unrestricted 'file' operator. So it was possible to make a PostScript file that would connect to the finger server and print out a list of anyone who was logged in. Or anything else if you can fish out a fork operator!
The NeWS source code is in that indeterminate "not lost but not published" state.
It would be a lot of fun and not so difficult to reimplement clean room NeWS in JavaScript from scratch, using canvas for all your PostScript rendering needs, which would otherwise be the hard part. James Gosling wrote the original SunDew interpreter in a weekend, but the graphics stuff took years to get right.
Gosling's SunDew paper: http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm
A few years ago I dabbled in writing a spec and some plumbing for NeWS in JavaScript, but haven't had the time to work on it recently. If anyone wants to work on it, I'd be happy to answer questions and put a little more time into it when I can.
Source code: http://donhopkins.com/home/sundew/sundew.js
It doesn't do anything exciting or graphical yet, since I was just working on the interpreter. So far I've classified and listed out all of the operators you'd need to cover, made nucleus classes for the vm, processes and objects, modeled shared bodies for dicts, array and string sub-intervals, stubbed out all of the NeWS primitive and magic dictionary data types, and stopped just short of writing the main interpreter loop in PSProcessBody.run, which will work a lot like ps.ps: http://donhopkins.com/home/code/ps.ps.txt
It still needs a lot of fleshing out, including a tokenizer (but that's trivial for PostScript) and many operators and graphics (but that stuff's fun!).
I'm sure that with some more work on a clean room JavaScript NeWS server, it would be both possible and legal to run a lot of the old NeWS 1.1 demos and apps like psiber, and maybe even later OpenWindows stuff like pizzatool, pretty darn fast in a web browser.
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.
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
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
NeWS was so awesome when it came out, where you can dynamically change the interface at any time. But NeWS had some horrible bits. As a language, it was very hard to read. If you saw a name, you didn't know if it was a variable or a function. That is, you didn't know if the value would be pushed onto the stack, or if it would pop some values off the stack. Best Practice was to add a comment after each line to indicate what the top of the stack would look like after that line. So if you got lost reading one line, you could figure out what the next line would do. But without it, after seeing three words in a row that you didn't fully understand, you were hopelessly lost.
NeWS (PostScript) was a write-only display model. You could not remove anything painted on the screen. You had to write over it. Adobe had Display PostScript, but that never took off.
And because of the write-only display, NeWS had a hard time freeing resources. Garbage collection was very difficult because of this. You would allocate a white square, and never truly "remove it" from memory. As I recall, a page refresh had to re-interpret all of the code - there wasn't any caching of the window.
Also - the entire display model with postscript-based scaling was CPU intensive, especially if you had a computer with slow graphics (quite common at the time).
Laser printers typically had a linear heap based memory allocation system that let you ensconce and roll back all modifications on a page with save/restore, but NeWS never used that for anything practical (although it did support it in a weird inefficient way of recording and reverting all mutations, which was more for backwards compatibility so the PostScript previewer could rendering existing PostScript documents that used save/restore, and never used in any interactive user interface toolkit or app outside a PostScript previewer).
Instead of a heap like a laser printer, NeWS used a reference counting garbage collection system, so once all references to an object were gone, it and any non-reachable sub-objects would be destroyed.
To work around problem of circular references leaking memory, later versions of NeWS supported soft reference counts: each object would have both a soft and a hard reference count, and you could soften a reference if you wanted to hold onto an object but be notified when it was no longer otherwise accessible. Once all the hard references to an object went away, if the soft reference count was still not yet zero, it sent out a /Destroy event on that object which anyone holding a soft reference to it must be listening for, and they clean up their reference in response to, and it's only deleted once its soft reference count goes to zero. It's a weak reference [2], but it used NeWS's built-in event distribution system to notify reference holders (since there was no way of PostScript code to hook into the destroy callback of an arbitrary dictionary).
Needing to use soft references directly wasn't very common in ordinary NeWS programming, and most uses were wrapped up behind the scenes by the toolkit (like the selection service listening for the selected object to be destroyed, text fields and menus pointing at each other for focus and pinned menu management, etc).
NeWS canvases could have a backing store that you could enable or disable, and they could be retained off screen, and top level windows were usually retained. Technically it was just a hint and you always had to be prepared to repaint in response to a /Damage event, but all servers supported retained canvases, and it still made sense to turn off retained mode in the case of simple efficient graphics on 24 bit color displays.
The art was in coming up with simple efficient ways of representing the data and generating the code doing the drawing in the server, so it could draw as fast as possible. Cool things were possible by dynamically generating PostScript code with inlined numbers, colors, fonts and other invariant parameters, in response to window resizing or layout changes and higher level data. You could inline calculated values into stupid-but-fast specialized instance methods (NeWS used a prototype based object system, that let you promote methods into instances), by using the PostScript equivalent of Lisp's "backquote" macro. [2]
[1] Weak References: https://en.wikipedia.org/wiki/Weak_reference
[2] TNT Slider Design Document: using PostScript "backquote" macro to cache efficient rendering code: http://donhopkins.com/home/archive/NeWS/tnt-sliders-design-2.txt
There exists a nice free e-book describing PostScript (Thinking in PostScript by Glenn C. Reid) [1].
[1] https://web.archive.org/web/20000914161447/http://www.rightbrain.com/download/books/ThinkingInPostScript.pdf
EDIT
While looking for the Thinking in PostScript book mentioned above, I stumbled upon this legal online archive for books on the net [2] which may be of interest to others.
[2] http://onlinebooks.library.upenn.edu
I love Glenn Reid's book, Thinking PostScript. It's like the Thinking Forth [1] of PostScript! ;) I always thought of PostScript as a cross between Lisp and Forth [2], but more in the Lisp camp, since it's so easy to write a metacircular evaluator [3] or a quine [4] in PostScript:
Do you remember Glenn Reid's "Distillery" [5]? It's a PostScript program that optimized other PostScript programs, which you prepended before your PostScript print file, sent to a printer, and it partially evaluated the PostScript code in the print file. It then echoed back another highly optimized flat PostScript program that printed the exact same pages, all in one coordinate system, with superfluous graphics state changes removed. That glorious hack, based on John Warnock's idea of redefining the imaging operators, eventually evolved into PDF! [6]Glenn also wrote a delightful "Font Appreciation" app for NeXT called TouchType [7], which decades later has only recently found its way into Photoshop.
I wrote a visual interactive PostScript debugging tool for NeWS called the PSIBER Space Deck [8], and the PseudoScientific Visualizer [9] for drawing PostScript data structures like NeWS object and class dictionaries or a network map of ARPANET IMPs, and a paper [10] about them. It was most useful for debugging itself, which was fortunate, since it was pretty buggy. I integrated the metacircular PostScript evaluator with the debugger, so you could single step through PostScript code, and draw graphics to visualize the program execution state. And I made my own NeWS distillery [11] "in the spirit of Glenn Reid's Distillery" ;), for making flat printable PostScript dumps of anything procedurally drawn on the screen, which I used for some of the illustrations in the paper [12].
[1] Thinking Forth: http://thinking-forth.sourceforge.net/
[2] PostScript -vs- Forth: http://donhopkins.com/home/code/ps-vs-forth.txt
[3] PostScript Metacircular Evaluator: http://donhopkins.com/home/code/ps.ps.txt
[4] PostScript Quine: http://donhopkins.com/home/archive/news-tape/fun/quine/quine
[5] Glenn Reid's PostScript Distillery: http://donhopkins.com/home/archive/postscript/newerstill.ps.txt
[6] The Distiller Story: http://blogs.adobe.com/insidepdf/2007/11/the_distiller_story.html
[7] TouchType: https://ftp.nice.ch/peanuts/GeneralData/Usenet/news/1990/_CSN-90/comp-sys-next/1990/Jul/_BaNG-%234-meeting-review.html
[8] PSIBER Space Deck Demo: https://www.youtube.com/watch?v=iuC_DDgQmsM
[9] Pseudo Scientific Visualizer Demo: https://www.youtube.com/watch?v=_fqCeuue5Ac
[10] The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines: http://www.donhopkins.com/drupal/node/97
[11] NeWS Distillery: http://donhopkins.com/home/archive/news-tape/utilities/cyber/distill.ps.txt
[12] Distilled PostScript PseudoScientific Visualization of Arpanet IMPS: http://donhopkins.com/home/archive/news-tape/documents/psiber/10.ps.txt