NeWS
|
|
NeWS, for Network extensible Window System, was a windowing system developed by Sun Microsystems in the late 1980s. Its primary architect was James Gosling, who subsequently designed Java. Based on PostScript (PS), NeWS started by modifing the PostScript interpreter to run in a cooperative multitasking fashion. Unlike PostScript in a printer, NeWS would be displaying a number of PS programs at the same time on one screen, so some form of multitasking was required. Contrary to popular belief, the NeWS interpreter was unrelated to Display PostScript and used different source code.
NeWS added a complete view hierarchy system, based on viewports known as canvases. Like the view system in most GUIs, it included the concept of a tree of embedded views along which events were passed. NeWS also included a complete model for events including timers and other "automatic" events, input queues for devices such as mice and keyboards, and other functionality required for full interaction.
But by far the most interesting addition was a complete object oriented (OO) programming style with inheritance. This eliminated the need for an external OO language to build a complete application.
Since all of these additions were added as additional PostScript keywords, it was possible to write simple PostScript code that would result in a running, onscreen, interactive program. For instance one of the common examples was an onscreen clock, which required about two pages of PS code.
NeWS also included a library (several actually) of user interface elements (widgets), written in NeWS. These widgets ran all of their behaviour in the NeWS interpreter, and only required communications to an outside program (or more NeWS code) when the widget demanded it.
For example, a toggle button's display routine can query the button's state (pressed or not) and change its display accordingly. The button can also react to mouse clicks by changing its state from pressed to not pressed and vice versa. All this can happen in the windowing server without interaction with the client program, and only when the mouse is released on the button will an event be sent off for handling.
This was more sophisticated than a "dumb" X Window System server, which can only report "mouse clicked on button" events to a client, which then has to switch the state, and finally instruct the server to display the new state. If client and server are not on the same machine, these interactions must travel over the network, slowing the feedback loop down unnecessarily.
The best example of such a toolkit is TNT (The NeWS Toolkit) which was released by Sun in 1989. Sun also shipped a smaller toolkit intended for example purposes and making small programs.
Several companies licensed NeWS and adapted it for various uses. There were only a few companies committed to this unproven technology. SGI used it to replace their proprietary GL windowing system. The OpenLook version of FrameMaker developed by Frame Technology Corp. with funding mainly from Sun Microsystems and NSA at the time was one of the few commercial products successfully run on NeWS. The freely-available X11 was already quite popular, so the first versions of NeWS emulated X11 by translating the calls into NeWS PostScript. Speed problems plus the existence of programs that relied on the exact pixel results of X11 calls, forced Sun to release an X11+NeWS hybrid called Xnews which ran an X server in parallel with the interpreter, which seriously degraded the NeWS interpreter performance and did not really result in a very good X server either. Sun also attempted to emulate the look & feel of OpenLook with a toolkit built on the same Xt (X Intrinsics) base as Motif, called OLIT, so that X programs could be made to look identical. After it was clear that OpenLook had lost out to Motif in popularity, and after Adobe acquired FrameMaker, products on NeWS simply vanished. Most UNIX workstations (including Sun's) now run the X Window System.
Why did NeWS fail?
There is no doubt that in many ways NeWS had a superior design for thin-networked clients, by moving much of the processing to the display, and separating graphical user interface semantics from client program semantics.
Possible reasons for its failure in the market include:
- NeWS needed to be licensed from Sun, while the source code for the X Window System was freely distributed under the MIT License. Any commercial code shipped using the NeWS libraries required licensing fees to be paid to Sun, Adobe Systems and Xerox PARC.
- The rest of the UNIX Workstation market was still catching up with other emerging network technologies that were invented by Sun (namely NFS). The rest of the UNIX Workstation market rushed to support the X Window System in an effort to undermine Sun's technology lead.
- NeWS lacked a robust library of reuseable code until well after the X Window System had become the dominant paradigm. This mistake was obviously not repeated in Java.
- PostScript is not a good programming language for humans. NeWS tried to make PostScript programming easier by adding object oriented extensions, but this did little to overcome the unfamiliarity of most software developers with the underlying PostScript language's syntax. Several "compilers" from C-like syntax such as pdb (PostScript Done Better) and c2ps were available, but were cumbersome to use and not supported by Sun.
- Writing NeWS apps required coding both client-side code and server-side code in two different programming languages. Communication between the two sides was very undeveloped and quite difficult.
- NeWS may have been ahead of its time and user requirements in the sophistication level of its graphical and user-interface capabilities.
- NeWS had much less of an advantage when the client and server ran on the same machine, and the network computing model never took off sufficiently to justify the extra complexity.
It is interesting to contrast NeWS with Display PostScript (DPS), which used the same underlying imaging model and language, but did so in a very different way. In DPS the PostScript commands were limited to what was needed to draw things, all other operations (such as creating a window to draw into) had to be implemented using other system interfaces. This lost interesting things like the ability to use a PostScript path to describe the shape of a window, and also meant DPS required you to use the quite horrible (but familiar) Xlib and some truly ugly code to make sure both DPS and X were agreeing about what to do. However it also meant that the majority of the system was located in compiled code, making it many times faster and considerably easier to write and debug. The result was a much smaller engine that offered the same end result — a PS-based display — that people thought was NeWS's purpose, but with higher performance and somewhat more "natural" programming.
External links
- NeWS origins (http://www.art.net/studios/Hackers/Hopkins/Don/lang/NeWS.html)