NeWS

NeWS teilt mit X die prinzipielle Aufteilung in einen Netzwerkdienst, der einerseits Zugang zu einem Bildschirm hat, der über Rastergrafik-Operationen ansprechbar ist, und andererseits Verbindungen zu den Anwendungen unterhält. Eine Anwendung kontaktiert dann entsprechend dem Client-Server-Modell den Dienst, um über die gemeinsame Netzwerkverbindung die zur Anwendung gehörenden Fenster darzustellen und die Eingaben des Benutzers zu empfangen.

Die Kommunikation zwischen dem Dienst und seinen Klienten (also den Anwendungen) erfolgt über ein Protokoll, das genau festlegt, welche Seite wann welche Form von Aus- oder Eingaben über die gemeinsame Netzwerkverbindung durchführen bzw. erwarten kann. Bei X stehen im Rahmen des Protokolls zahlreiche Operationen mit genau festgelegten Parametern zur Verfügung. Genauso ist auch festgelegt, welche Ereignisse (wie etwa Mausbewegungen oder Eingaben über die Tastatur) mit welchen Daten den Weg vom Dienst zum Klienten finden können.

Im Vergleich dazu verzichtet NeWS auf einen festen Satz an Operationen und Ereignissen und stellt stattdessen eine auf PostScript basierende Programmiersprache zur Verfügung. Das bedeutet, dass die Anwendung beliebigen Programmtext zum NeWS-Server schicken kann, der dort die Möglichkeit hat, als eigenständiger Thread zu laufen, der dann wiederum selbständig die Kommunikation mit dem Klienten organisieren kann. Das hat zur Folge, dass ein Teil der Anwendung (wie bei X) im Klienten läuft, zusätzlich aber ein Teil der Anwendung (anders als bei X) auch beim NeWS-Server residiert.

Diese Aufteilung hat den Vorteil, dass die Leistung deutlich verbessert werden kann, da viele Aktionen einer Anwendung keine Kommunikation über das Netzwerk benötigen und der verbleibende Umfang der über die Netzwerkverbindung ausgetauschten Daten dank der sehr individualisierbaren Netzwerkkommunikation deutlich reduziert werden kann. Ein typisches Anwendungs-Szenario könnte etwa so aussehen: Die Anwendung lädt zunächst Programmtext auf den NeWS-Server, der ein größeres Formular mit vielen Eingabefeldern darstellen und betreuen kann. Der im NeWS-Server arbeitende Teil der Anwendung kümmert sich dann um all die Ereignisse zum Ausfüllen der einzelnen Felder und nimmt vielleicht auch einfache semantische Überprüfungen vor. Wenn dann schließlich der Benutzer über eine Schaltfläche signalisiert, dass alle Felder ausgefüllt sind, werden die eingegebenen Daten in kompakter Form an den anderen Teil der Anwendung über die Netzwerkverbindung zugeleitet.

Diese Vorgehensweise erinnert an die von Webanwendungen, die Programmtexte in JavaScript an die darstellende Seite beim Benutzer verschicken. Auch hier ist zum Ausfüllen der Felder keine Interaktion mit dem eigentlichen Web Service notwendig; erst mit dem Abschicken erfolgt der Versand der ausgefüllten Daten über das Netzwerk. Anders als bei Webanwendungen war NeWS jedoch weitaus flexibler, da die Netzwerkverbindung ständig aufrechterhalten wurde und die Kommunikation sich vollkommen frei gestalten ließ.

Noch näher an die alte Funktionalität von NeWS kommen Java-Applets, bei denen ebenfalls Anwendungsteile (Applets genannt) zur anzeigenden Seite heruntergeladen werden. Hier hat das Applet die Möglichkeit, eine frei benutzbare Netzwerkverbindung zur Seite des Webdienstes zu eröffnen und über längere Zeit offen zu halten. Die Ähnlichkeit der Architektur von NeWS und die der Java-Applets ist nicht zufällig, da letztere ebenfalls unter der Leitung von James Gosling entwickelt worden ist.

Die Architektur von NeWS zog einen weiteren wesentlichen Unterschied im Vergleich zu X nach sich. Grafische Anwendungen benötigen umfangreiche GUI-Toolkits für Elemente der Benutzeroberfläche wie etwa Schaltflächen, Eingabefelder und Menüleisten. Bei X-Anwendungen werden diese zur Anwendung dazugebunden und sie kommunizieren somit mit dem Server nur über das Netzwerk. Bei NeWS ist es hingegen zur Ausnutzung der Vorteile der Architektur notwendig, das Toolkit in NeWS zu programmieren und dieses in den NeWS-Server zu laden. Nur wenn dieses direkt beim NeWS-Server zur Verfügung steht, kann es auch von dem Anwendungsteil genutzt werden, das beim NeWS-Server läuft.

Schon früh wurde NeWS von Sun an mehrere andere Hersteller lizenziert, darunter insbesondere auch Silicon Graphics. Eine größere Verbreitung erreichte NeWS jedoch nie, da kaum Anwendungen dafür entwickelt wurden. Dies wurde auch dadurch erschwert, dass Sun erst 1989 mit TNT (The NeWS Toolkit) ein passendes Toolkit zur Verfügung stellte, zu einer Zeit, zu der X längst hohe Verbreitung erlangt hatte. Zu den wenigen größeren dennoch entwickelten Anwendungen gehörten FrameMaker, das von Arthur van Hoff entwickelte HyperLook und das Spiel SimCity. Keine davon erreichte in der NeWS-Fassung besondere Verbreitung.

Dem Problem, dass Nutzer nur ein Fenstersystem gleichzeitig nutzen können und somit nicht gleichzeitig NeWS und X11 mitsamt den zugehörigen Anwendungen laufen lassen können, versuchte Sun 1990 mit der Einführung eines hybriden Servers X11/NeWS zu begegnen, der sowohl das X11-Protokoll als auch NeWS unterstützte. Dieser hybride Server war von SunOS 4.1.1 bis Solaris 2.3 zusammen mit TNT Bestandteil des Betriebssystems. Als aber an der Popularität von NeWS sich nichts signifikant veränderte, gab Sun den hybriden Server wieder auf und bot beginnend mit Solaris 2.4 nur einen reinen X11-Server an. Stattdessen begann James Gosling bei Sun mit der Entwicklung von Java.

NeWS fand ein zweigeteiltes Echo. Einerseits fand die Architektur Anklang und andererseits waren die Rechner Ende der 80er und Anfang der 90er Jahre den Anforderungen von NeWS nicht immer gewachsen. Aus dem Vorwort des Buches von Elke Heck und Fred Kumpmann:

Wir haben in dieser Zeit die Erfahrung gemacht, daß es sich bei NeWS um ein wirklich leistungsstarkes Window-System handelt. Durch seine Fähigkeiten, Windows verteilt über ein Netzwerk zu verwalten, und die durch PostScript gebotenen graphischen Möglichkeiten stellt NeWS eine geeignete Basis zur Entwicklung verteilter Anwendungen dar.

In der zusammenfassenden Beurteilung des gleichen Buches finden sich aber auch kritische Anmerkungen:

Als überlegenswert an NeWS herausgestellt hat sich die Tatsache, daß alle Window-, Maus-, Menü- und Tastaturverwaltungsroutinen in PostScript programmiert sind, daß sie somit jeweils bei ihrer Ausführung vom PostScript-Interpreter, der naturgemäß nicht besonders schnell sein kann, interpretiert werden müssen. Diese Verwaltungsroutinen haben keine höhere Priorität gegenüber ‚normalen‘ graphischen Anwendungen, so daß interaktives Arbeiten mit NeWS schon bei einigen wenigen im Aufbau befindlichen Graphiken durch die hohe CPU-Auslastung und die daraus resultierende lange Antwortzeit für Benutzeraktionen sehr erschwert wird.

Ein ähnliches Konzept mit verteilten Fenstern und Postscript findet sich auch in NeXTStep (ab 1988).

• James Gosling, David S. H. Rosenthal und Michelle Arden: The NeWS Book: An Introduction to the Network/extensible Window System. Springer-Verlag, 1989, ISBN 0-387-96915-2.
• Elke Heck und Fred Kumpmann: NeWS – Das Netzwerk-fähige Window-System. Springer-Verlag, 1990, ISBN 3-540-52063-5.

1. Architech Readies OS/2 Version of NewsInterface, zusätzlicher Text.

Commons: NeWS – Sammlung von Bildern, Videos und Audiodateien

• Rückblick auf NeWS von Don Hopkins
• Rückblick auf die Hyperlook-Anwendung von Don Hopkins