NeWS tries to shoehorn all of human activity into one language -
Gosling's ``almost PostScript'' [it's a while since I used it; sorry
for this remark if it's a real clonse these days]. The small number
of things you can do with a window produced a moderate number of
incompatible extensions to PostScript. One can imagine that the
wide variety of things you can do wiht 3D rendering would cause an
operator and data type explosion. And what about image processing?
In a nutshell: bare X is good for writing terminal emulators. NeWS
is good for DTP. But there's a lot more out there, and at least X
makes it possible in standardised ways, even if it is uncomfortable.
I can imagine a ``tomorrow window manager'' that has lots of individual
``graphics language'' processors that chat to each other (did I say
this ran under UNIX?:->), and like all tomorrow systems, it would
presumably have a ``Cobol mode'' that let you interpret the X11 core
protocol too. NeWS might be part of that, but it certianly couldn't be
the whole thing.
--
Ian D. Kemmish Tel. +44 767 601 361
18 Durham Close uad...@dircon.co.uk
Biggleswade uknet!dircon!uad1077
Beds SG18 8HZ United Kingdom
> But NeWS is -much- more than just PostScript+windows. There is the
> input/event model previously mentioned. And it is a true Object-Oriented
> language/environment that is unparalled short of lisp. (Dynamic inheritance,
> multiple inheritance, classes are objects, etc.) Actually, PostScript
> is the -least- interesting part of NeWS.
The 80's have seen the development of local networking. The 90's will
see the raise of interactive mondial networking. As I will
demonstrate it, X just does not fit the bill.
Suppose that I have an application running in Europe which interact
with me in the US. I can't tolerate that my interaction with the
user interface of the application is always slower than one second.
When I push a button, I want to see it immediately. When I type in a
text-field, I want the characters to appear immediately. I can easily
tolerate that the application itself is slow as long I am sure that I
see immediately that the button is pushed (or whatever widget state is
modified) . I know I have interacted correctly and I can rest before
the application replies to my interaction.
A NeWS application can download all the code which performs this
"short term interaction" on your workstation. So, this "short term
interaction" is quasi immediate.
With X, there is always a round-trip between the application server
and the window server, ...and an unproductive load of the application
server: the input must go from the window server to the application
server, must be processed by this application server, and the feedback
must go its way back to the user. At least one second...
And don't forget, with the new networking technology, you will pay
the quantity of information which transits instead of the time of
connexion.
stef
--
Stephane Payrard -- stephane...@eng.sun.com -- (415) 336 3726
SUNPICS 2550 Garcia Avenue M/S 10-09 Mountain View CA 94043
No, it isn't quite a perfect clone; but in many ways it is extended
way beyond (D)PS. In particular, it offers an input and event model
which is generally agreed to be cleaner (read better) than X's. And
most of the race conditions that plague the X world (even with the
conventions to handle them) don't occur in NeWS at all.
It is also somewhat misleading to imply that DPS is any sort of standard
or that DPS programs are portable. Since each vendor is explicitly free
to extend and modify the API, a majority of DPS programs are actually
linked to a single vendor's implementation.
> The small number
> of things you can do with a window produced a moderate number of
> incompatible extensions to PostScript. One can imagine that the
But NeWS is -much- more than just PostScript+windows. There is the
input/event model previously mentioned. And it is a true Object-Oriented
language/environment that is unparalled short of lisp. (Dynamic inheritance,
multiple inheritance, classes are objects, etc.) Actually, PostScript
is the -least- interesting part of NeWS.
> One can imagine that the
> wide variety of things you can do wiht 3D rendering would cause an
> operator and data type explosion. And what about image processing?
Or one could imaging some very smart people defining a few flexable,
general extentions that can handle it all. One could also imagine
the ability to dynamically extend the NeWS interpreter with loadable
modules and a namespace quantizing mechanism. (See packages in OW3.)
> In a nutshell: bare X is good for writing terminal emulators. NeWS
> is good for DTP. But there's a lot more out there, and at least X
> makes it possible in standardised ways, even if it is uncomfortable.
Bare X isn't good for much at all. Compare xterm with jet (the NeWS
vt100 emulator in OpenWindows V3.) The percieved performance is about
the same; but Jet supports both scrolling and curses-type direct screen
manipulation simultaniously. It supports all fonts availiable in NeWS.
It allows you to choose whether resizing the window should change the
number of characters displayed, or their size. It has four scrolling
modes (supersmooth, smooth, jump, superjump.) All of which is nice
and whizzy, but the real win is that for every key typed in a jet window
exactly seven bytes of data are transferred between the server and the
client (3 one way, 4 the other.) For xterm the total is about 180.
This means that Jet is -very- usable over a 9600 baud connection.
And Jet is about 1/3 the size of xterm.
> I can imagine a ``tomorrow window manager'' that has lots of individual
> ``graphics language'' processors that chat to each other (did I say
> this ran under UNIX?:->), and like all tomorrow systems, it would
> presumably have a ``Cobol mode'' that let you interpret the X11 core
> protocol too. NeWS might be part of that, but it certianly couldn't be
> the whole thing.
There is a very good (but not yet availiable) X/NeWS window manager written
in NeWS. It provides both `rooms' and `virtual space' paradigms simultaniously
and has performance comparable with (or sometimes better than) ol(v)wm. It
consists of about 9000 lines of NeWS (PostScript) code [about 50K] and 900
lines of `c' (both including comments.)
It is important to recognize that (almost) nobody programs in PostScript.
They write programs that emit PostScript. But NeWS is a real programming
environment, and NeWS programs use NeWS for much more than rendering.
-Pat
PMLashley plas...@Sun.COM SunSoft:NeWS Tools & Services
"I haven't lost my mind -- it's backed up on tape somewhere..."
"X11: Complex non-solutions for simple non-problems."
I seldom comment on NeWS; some might claim I'm biased :-). From my
view, few people actually name the real reasons for NeWS's failure, in my
book; but I refuse to comment on that; the arguments got tedious 3-4 years ago
from where I sit.
But I can't resist the temptation to insert fact into a discussion, when facts
seem hard to find.
If you are going to make the argument above, you'll find it doesn't hold water very well.
From Digital here in Cambridge, we have a T1 line to Palo Alto, California.
These days, most circuits are land lines (remember what fiber optics has been doing
to cable economics). And most people find they really don't like satellite channels
for networks, unless they are in the bulk data transfer buisness.
CRL to Palo Alto is of order 2/3rds the distance to Europe. Below is
a ping the gateway machine in Palo Alto; note that 4 ms. of the 70 is local
to Cambridge (two gateways locally). I'm too lazy to figure out what the packet
delays are on each end at 1.5 megabits.
So Europe, over a decent network, should be around 100ms round trip, not the one second
you are claiming. And T1 is networking of the late 80's, rather than networks of the
mid to late 90's (though speed of light never gets any faster, gateway and packet
transmission delays are on the way to vanishing).
quabbin % ping nsl-crl.p-p.dec.com
PING nsl-crl.p-p.dec.com (16.10.16.37): 56 data bytes
64 bytes from 16.10.16.37: icmp_seq=0. time=74. ms
64 bytes from 16.10.16.37: icmp_seq=1. time=70. ms
64 bytes from 16.10.16.37: icmp_seq=2. time=70. ms
64 bytes from 16.10.16.37: icmp_seq=3. time=70. ms
I routinely, when visiting Palo Alto, run my X applications in Cambridge over
our T1 circuit; it is observably slower, but perfectly usable.
Now, clearly Australia is more of an issue, as the moon would be. But, unfortunately,
I don't anticipate a tourist visit to either very soon.
> --
> Stephane Payrard -- stephane...@eng.sun.com -- (415) 336 3726
> SUNPICS 2550 Garcia Avenue M/S 10-09 Mountain View CA 94043
--
Jim Gettys
Digital Equipment Corporation
Cambridge Research Laboratory
I can imagine a ``tomorrow window manager'' that has lots of individual
``graphics language'' processors that chat to each other (did I say
this ran under UNIX?:->), and like all tomorrow systems, it would
presumably have a ``Cobol mode'' that let you interpret the X11 core
protocol too. NeWS might be part of that, but it certianly couldn't be
the whole thing.
What I suspect you will see is a "user interface server," which will handle
all interaction with the user (including graphics, sound, video, etc.), as
well as supporting much more distributed processing for applications.
NeWS is a great testbed for playing with this, but the real thing will
have to be a lot broader. However, NeWS is the only thing that's even
in the running when it comes to basic design. If X survives, it will
be because people will layer things like NeWS on top of it.
Amanda Walker ama...@visix.com
Team Leader ...!uunet!visix!amanda
Visix Software Inc. +1 800 832 8668
--
<Deadly ninja throwing .signature>