is news loosing the battle?
Don Hopkins
First of all, let me point out that I think the question "Is NeWS
loosing the battle?" is totally meaningless. Right up there with
"Is NeWS tighting the war?" sic(-;
The X11/NeWS merge will be widely available as a standard part of AT&T
Unix. A battle between X and NeWS is as pointless as a battle between
VT100 escape sequences and Tektronix control codes! They're both
widely supported and emulated standards, each one best for certain
applications, and neither has destroyed the other. Terminal emulators
such as xterm support both standards, and I don't think DEC is out to
discourage people from using xterm's Tektronix features.
Date: Thu, 7 Jul 88 19:52:37 EDT
From: hpda!hp-sde!hpfcdc!hpfclp!dia...@ucbvax.Berkeley.EDU (John Diamant)
Non-rectangular windows is "gee whiz," but frankly, I don't care
about that at all. Other than having round clocks, I just don't
see this as a big deal.
Sheez, some people are so stuck in the rut of rectangular windows,
that when I tell them that NeWS has arbitrarily shaped windows,
they assume I mean arbitrary rectangles ...
Non rectangular windows are invaluable for many applications! It's
the kind of thing that once you're used to, you'll never want to do
without!
The shape of a NeWS window ("canvas") is defined by a PostScript
path. They can have lines, arcs, bezier curves, and conic splines as
edges. They can even have holes in them, and disconnected regions!
You can use either the even-odd or the zero winding rule to define
what's inside and outside the path.
The shape of a canvas influences the clipping of graphical output,
and the distribution of input events.
Each canvas has its own default coordinate system, the one that
was in effect when it was reshaped.
Canvases can be used as arbitrarily shaped targets. NeWS processes
can receive input events whenever the mouse enters, leaves, clicks,
or moves around in a canvas, and event coordinates are reported in
terms of the process's current coordinate system.
NeWS canvases are natural to use as animated "sprites", using
lightweight PostScript processes to periodically blink, move, or
paint them. (This is a great way to implement a cursor, or a space
invader!)
Transparent canvases are like opaque canvases in that they have
arbitrary shapes and coordinate systems, effecting clipping and
event distribution, except that they don't have their own image --
the image of their (first opaque) parent canvas shows through.
Graphical output on a transparent canvas gets clipped to its shape,
and drawn through into the parent's image.
A hypermedia browser that I'm porting to NeWS for Ben Shneiderman,
called HyperTIES, displays documents containing text and graphics
with "embedded menus" of links to other documents. Embedded menu
buttons are overlayed on top of text and graphics, and highlight
when you move the cursor into them.
In NeWS HyperTIES, the embedded menu buttons are simply implemented
using transparent canvases. Text buttons use canvases overlayed on
top of words in text, shaped like rounded rectangles. Graphical
buttons use canvases overlayed on top of parts of pictures, shaped
like the Hubble Space Telescope, a Faint Object Spectrograph, a
circle, a pie slice, Bill Joy's head, a rabbit, a mouse pad, or
whatever part of a picture you want to link to some document!
When the mouse moves into a button, there is some feedback to show
that it can be pressed, such as a color change, animation, or a
pop-up cut-out magnified image cookie with a shadow behind it. (Just
map a pre-fab opaque canvas with the translated and scaled image and
target shape!)
The ability to have interpretive toolkits which can be swapped is
useful, but there are other ways to accomplish this in X as well
(using dynamic loading, for instance).
There is a big difference between dynamically loaded toolkits, and
toolkits written in an interactive interpretive environment. With
NeWS, I can interactively debug PostScript code running in the
server -- looking and and changing the values of variables,
calling and redefining functions, setting breakpoints, examining
and changing the execution state of lightweight NeWS processes,
etc...
The NeWS "Lite" user interface toolkit is based on Owen Densmore's
object oriented programming package, a smooth fitting extension to
the PostScript language. With Bruce Schwartz's class browser, you
can interactively examine all the classes defined in the server.
Toolkit hacking is *easy* to do in NeWS. For HyperTIES, I extended
the NeWS "Lite" toolkit by making a Target subclass of Item, that
highlights when the mouse moves into it. I then made subclasses of
Target to do the kinds of highlighting I wanted for my application.
When HyperTIES is run, it checks to see if the Target classes are
defined in the server, and loads them in if they're not.
I can hack on the pieces of the application interface and toolkit,
reload 'em into NeWS, test them out, fix a bug, load 'em back up
and try it out again, tweak a variable, play around some more,
stick in some debugging statements, frob it until I get that funny
condition, scrutinize a broken process's state, reach inside and
redefine a function, continue the process, frob it mercilessly,
sigh in relief, and then update the source code, iteration after
iteration after iteration, all without restarting the NeWS client
or recompiling anything at all!
Probably the most significant difference between X and NeWS is the traffic
between client and server.
No, EXTENSIBILITY is the most significant difference between X and
NeWS. Low client/server traffic is just one of the many advantages
that comes from it. X is just not extensible the way NeWS is.
An X11 client can ask the server if certain predefined extensions
are available, and if they're not, the client can either give up
or do without.
NeWS extensibility is much more finer grained and application
specific -- a client can load its own extensions into the server,
teaching NeWS to communicate in whatever protocol is most convenient
for the application. It's a dynamic protocol -- clients can make
local or global extensions, on the fly! For example, when a CAD
program needs to draw a particular integrated circuit for the first
time, it could send the IC's name and a function to draw it, then
extend the protocol by associating a token with the function. From
then on, it can just send the token to draw the IC.
First of all, Scheifler wrote a paper about why the traffic
breakdown wouldn't be as good as the claims (because the
communication for even simple operations like menus would be higher
than expected).
I don't think that's true. With NeWS, all the clients share the
same menu code, which runs entirely in the server. There is no
network traffic at all involved with making a menu selection in
NeWS. The only communication that is required is informing the
client of the results of the selection (which could be as terse as
a one byte token -- who needs fixed size packets?). In many cases,
the selection can be acted upon entirely in the server!
One of the big advantages NeWS has over X in network utilization
is that for many applications, repainting a window can be handled
entirely in the server. Instead of the client responding to every
damage event (when the window is exposed or resized), it sends to
the server a program to paint the display (or a display list, and
a program to interpret it), which is executed whenever needed.
Second of all, it doesn't really matter! I'm a network
administrator and I have some experience on this subject. Lan
bandwidth is rarely the bottleneck in communications between two
machines. We run diskless (including remote swap), remote X, etc.
and the volume of traffic is just never that high (typically under
5% of lan utilization).
That sure doesn't agree with the numbers I've heard for the % of lan
utilization on nets with with diskless workstations. The way
diskless clients eat up the net severely limits the number of them
that can coexist on one piece of cable. I think network utilization
is a very important factor. I want to be able to run clients over the
Internet, and over the phone!
Also, most X servers run with Unix Domain sockets when running
locally, so lan overhead isn't a big issue.
When you run clients locally, paging and context switching become big
issues. (Are you paging over the net? Even more fun!) With X, if you
run your window manager locally, and it rubber-bands a rectangle when
you resize your window, there must be a Unix process context switch
from the server to the window manager, and back to the server, every
time you move the mouse. It's a big win to have the window manager
running in the same Unix process as the server. No frantic context
switching, and the WM does not need to keep its own copy of all those
data structures that live in the server. With NeWS, switching to a new
window manager is as easy as redefining the DefaultWindow class. With
X11/NeWS, NeWS window managers can manage X windows, too!
The only issue that remains is the performance in terms of
throughput on the lan. We are already at the point where lan
performance is within the same ballpark as disk transfer rates, so
it isn't that big a deal, and we're getting faster lan technology
too.
Disk transfer rates just don't cut it when compared to memory
transfer rates. We're getting faster and faster processors, as
well! Do you really think that advances in lan speed are going to
be able to keep up with advances in processor speed? I doubt it!
-Don
Don Hopkins
d...@brillig.umd.edu
...!uunet!mimsy!don