The fact that the web finally ended up the way it did, with a so-called "AJAXian" architecture using JavaScript in the web browser (and often the web server too) (not to mention the PostScript Stencil/Paint imaging model in canvas), instead of a fixed protocol like X-Windows (stuck with its terrible obsolete imaging model), certainly proves my point that NeWS's architecture of sending code instead of a fixed protocol like X-Windows is by far the superior, more efficient, future-proof, open-ended architecture.
The term "AJAX" was coined in 1999, but NeWS (aka SunDew) was doing it in 1985, 14 years before the term "AJAX" was coined in 1999. And X-Windows still isn't doing it, 37 years after James Gosling originally proposed that architecture in his paper describing SunDew.
https://en.wikipedia.org/wiki/NeWS
>NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:
>used PostScript code instead of JavaScript for programming.
>used PostScript graphics instead of DHTML and CSS for rendering.
>used PostScript data instead of XML and JSON for data representation.
I worked on the display driver for the NeWS version of Gosling/UniPress Emacs, and also on the NeWS display driver for Gnu Emacs, and thanks to NeWS's ability to download code that implements application specific protocols, both versions of Emacs ran quite smoothly, efficiently, and responsively over slow dial-up modems, ISDN, and the slow internet connections of the late 80's - early 90's.
Here's an email I sent to James Gosling in 1988 describing how the Emacs display driver I implemented for UniPress Emacs 2.20 works, by providing smooth live text selection feedback without requiring client/server round trips every time the mouse moves, as well as interactive pie menus and tabbed windows, all implemented in PostScript in the NeWS server:
https://www.donhopkins.com/home/archive/emacs/to.jag.txt
>Hi! I'm working on Emacs this summer at Unipress. It now supports menus, and text selection, with rubber banding in the server. It works, and is much fun to use, but I have a few questions about getting it RIGHT!
>When you initiate a selection by clicking with the mouse, emacs replies with an array of the line widths in the current window, and the row of the window's top line. Some code I stole from nterm rubber bands an outline around the text as you drag around the window. I modified it to show that a line's trailing newlines was selected by drawing the right edge with an arc or a slant.
>[...] Other stuff we're working on include a menu compiler, which compiles nested menus described as linked info nodes into PostScript code and MLisp key bindings. (Menu keys are assigned keystroke sequences, with keytop names that identify them, which are bound to MLisp functions. Menu keys can invoke submenus or do anything else you want, too.) So you can make menus without touching PS or MLisp! The menus all run in the server, so you can type into the emacs underneath while you're in the middle of completing a menu selection. I changed getmenuaction to execute executable keywords, to support indirect submenu references, and magic functions that decide the submenu or menu action.
>[...] I made a class of window that has thin borders, and a little handle sticking out the top right with its FrameLabel -- you can have a bunch of them overlapping, and their names all stick out to the right, where you can click on them to bring them to the top or get a frame menu. They work really well with multiple emacs frames!
>Thanks for all the neat toys!
Here's a screen snapshot of that code running, from the wikipedia page about tabbed windows:
https://en.wikipedia.org/wiki/Tab_(interface)#/media/File:Hy...
And here's the PostScript source code of the emacs client side display driver:
https://www.donhopkins.com/home/archive/emacs/emacs.ps
Also, in case you weren't aware, a single X-Windows "client" can have simultaneous connections to multiple X-Windows "servers", in the same way that a single web "server" can have simultaneous connections to multiple web "browsers".
A good example is SimCity (aka multi player SimCityNet and open source Micropolis), which is a commercial product that I developed for NeWS in PostScript, for X-Windows in TCL/TK (later releasing a single player version as Micropolis for the OLPC), and a multi player open source version for web servers in Python (whose distributed client/server "AJAXian" architecture was most similar to the original NeWS version, no matter how you label the client and server).
The TCL/Tk/X11 version of multi player "SimCityNet" supported simultaneous connections to several players on different (or the same) X-Windows servers at once, so they could play together in the same city.
Product Announcement: Multi Player SimCity for X11 is now available from DUX Software! (1993):
https://www.donhopkins.com/home/catalog/simcity/simcity-anno...
SimCityNet: a Cooperative Multi User City Simulation (1993 INTERCHI Amsterdam demo)
https://www.donhopkins.com/home/catalog/simcity/simcitynet.h...
Multi Player SimCityNet for X11 on Linux. Demo of the latest optimized Linux version of Multi Player SimCity for X11. Ported to Unix, optimized for Linux and demonstrated by Don Hopkins:
https://www.youtube.com/watch?v=_fVl4dGwUrA
Micropolis Online (multi player SimCity running on a web server in Python) web demo. A demo of the open source Micropolis Online game (based on the original SimCity Classic source code from Maxis), running on a web server, written in C++ and Python, and displaying in a web browser, written in OpenLaszlo and JavaScript, running in the Flash player. Developed by Don Hopkins.
https://www.youtube.com/watch?v=8snnqQSI0GE
Unfortunately the support for multi-player applications in X-Windows toolkits like TCL/Tk was buggy and incomplete, so I had to fix it for SimCityNet, and the support for security and authentication in X-Windows is STILL abysmally terrible, so I had to drop the multi player feature from the OLPC version of Micropolis, because I wouldn't want to require children to type "xhost +" or enter hexadecimal magic cookies and ip addresses to play a game.
But it was much safer and easier to implement a secure multi player game in Python on a web server over https to multiple simultaneous web browsers.
Here's the Python source code of the web server, which uses the C++ reimplementation of SimCity called MicropolisCore via SWIG wrappers:
https://github.com/SimHacker/micropolis/blob/master/turbogea...
And to demonstrate what I mean by downloading procedural code implementing custom compression protocols between client and server instead of using a fixed protocol, and communicating using efficient application specific protocols instead of rigid fixed protocols like X-Windows, here is a concrete example you can see for yourself.
This is the server side of the tile compression protocol: GetTileData returns a buffer of compressed tile differences (of only the tiles the user can currently see) to send to the browser, which is further optimized to support SimCity's notion of "animated tiles", so it doesn't even have to send deltas for tiles that are automatically animate in the client, or outside of the user's scrolling view:
https://github.com/SimHacker/micropolis/blob/master/Micropol...
The Python code running in the web server gets the compressed tile data and sends it to the client:
https://github.com/SimHacker/micropolis/blob/master/Micropol...
The JavaScript code running in the web browser receives the compressed tiles, decompresses them, and updates the tile view:
https://github.com/SimHacker/micropolis/blob/master/laszlo/m...
The resulting distributed real time animated user interface is quite snappy and responsive over the network (especially the pie menu, which track input, interact, and display feedback locally, and only send messages to the server upon completion), as you can see in the demo video above.
Are you following along so far? This "AJAXian" architecture is precisely what James Gosling was writing about 36 years ago in 1985, when he described the client interaction of "SunDew", which was later renamed "NeWS":
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
>5.3.4 Client Interaction
>Client interaction with the window system can be broken down into three layers: messages that get passed between the window system and the client, the programs that are contained in the messages, and a procedural interface to program construction. This is one of the key unique points about this window system: clients send programs to the window system whose elaboration causes graphic operations to appear. The client program does not send graphic operations directly. There is, of course, a procedural interface to program construction that blurs the distinction.
>This approach allows the client to redefine the protocol to compress messages passed to the window system. For example, if the client wishes to draw a grid it can download a procedure which iteratively draws the lines, generating their coordinates as a function of the loop index. This is a substantial compression over transmitting a large set of lines, even if the grid is drawn only once. There are other performance advantages: message-passing interactions are relatively slow and downloading a procedure that will respond locally eliminates this overhead. For example, if a client program needs rubber band lines, then rather than have the window system send a message to it each time the mouse moves, it can download a procedure that will track the mouse locally.
>There are a number of features of PostScript that make it attractive. It is very simple, and it is complete. Its simplicity makes it fast to translate and interpret - this can almost be done as quickly as packets can be disassembled in a more traditional IPC environment. Adobe did a very good job of designing a set of primitives and data structures that fit together well. Its chief drawback is that it can be hard for people to understand; the postfix notation is well-suited to consumption and generation by programs, but humans find it obscure.
>It is important to think about the client programmer's model of what the window system does. We expect there to be two levels of model. The first completely hides the existence of PostScript with a veneer of procedure calls that construct and transmit fragments of PostScript programs. The second exposes PostScript. Beyond a certain level of functionality, learning PostScript is inevitable: it can be pushed off by making the veneer more comprehensive, but this just makes the eventual leap harder.
#/media/File:HyperTIESAuthoring.jpg){kind=link}