Subject: [[email-masked]: Some thoughts on NeWS]

From: [email-masked]
Date: Wed, 8 Apr 87 20:11:13 EST

Date:  8 Apr 87 08:48 EST
From: [email-masked]
Subject: Some thoughts on NeWS
To: [email-masked]

Several people locally have asked me to comment on NeWS - why its good
and where its bad.  This message is the result.  I speak as someone
who has been building something in NeWS for a while, and who has poked
around in it reasonably extensively.  That does not mean that i can be
considered a NeWS expert by any means, there are certainly places
where i have missed things (sometimes embarassingly), and i cant claim
to have explored even the parts that i know as well as i would like.

On the whole, i like NeWS.  I have compared NeWS to X, and to
suntools, and at this point NeWS comes up the clear technical winner.
This is mostly because NeWS does have an embedded programming
language, and i tend to believe that this is generally a Good Thing.
In the case of window systems, i think that it is a Very Good Thing,
as it clears the way for intelligent 'terminals' that can run the
window system, and offload much of the burden from servers.  In fact,
the more of the burden that can be handled on the 'terminal' the
better.  A programming language living in the window system then
facilitates such load sharing, and by being extensible, allows
different applications to download different parts of the work that
needs to be done.  The downside of this is that it requires processing
power, and traditionally, that has not been available in the terminal.
However as chips become cheaper it becomes more reasonable to put
computing power in the 'terminal'.

Why PostScript (extended) as a language?  Proponents of C, Smalltalk,
Lisp, Fortran, Ada...  probably all feel that their favorite language
is the best for a window system, and good arguments can probably be
mustered for all (well most) of them.  I think though that PostScript
is an excellent choice.  It was designed for graphics, its small but
easily extensible, and it is quite simple.  Aesthetically too,
PostScript is rather elegant. Further, with the Forthesque stack
model, PostScript is probably well suited for implementation in
hardware.  On the down side, PostScript does require some care in
coding (at least initially) as keeping track of things is sometimes a
bit complicated.

There are dark clouds though.

First, the communications model has some problems.  These problems do
not arise when you just connect to the NeWS server and type in
postscript (which is quite possible, and very handy for debugging),
but rather in communicating to programs.  The C to NeWS interface
looks (from the C end) rather like a C function call, and may return
results.  But from the NeWS end it is rather kludgy.  It involves
printing out a tag, then the results wanted.  The C routine then waits
for that tag on the NeWS stream and interprets the results.  (If
another tag comes along, the function call returns an error.)  This
works, and works well for simple do-this-and-get-results type calls.
The problems arise when you need to look for asynchronous results from
NeWS (and potentially other input streams).  The suggested model is to
loop through all the possible functions that may expect input until
one succeeds.  I think this is probably sufficient for small programs,
but will probably not succeed well for larger ones. Clearly the
problems with asynchronous input are difficult, but a better interface
is needed.

Second, and far more problematical, it is not easy to see where to
draw the lines in building any particular application.  That is, where
do i do something in C (or Ada or...) and where do i do it in NeWS.
Unhappily, there are no easy answers.  Consider an application that
needs to place a bunch of boxes on the screen, and those boxes are
shaped by something on the NeWS end.  (They need to be big enough to
hold specified text or graphics, or the user will size them, or
whatever.  It should be understood that unless the information is
shipped up, the C application does not know how big the fonts, or
characters in them are.)  Who knows how big the boxes are, and where
they are?  News alone?  Thats fine unless the placement algorithm is
tricky, or if a lot of code needs to be sent to NeWS to handle things.
C alone?  Thats fine, but the application may then need to go asking a
lot of questions about the size and location of the boxes.  Also, if a
repaint screen is requested a lot of stuff may need to be shipped down
to NeWS. Both C and NeWS?  Now we have lots of copies of our data, and
they must be kept in sync which may up the communications bandwidth.
This is not a problem inherent to NeWS, clearly, but a problem common
to many distributed systems.

Third, debugging is a pain.  The situation begins with an
application running (say) C code that is sending code in PostScript
down to a server which (often) forks off processes that will
send stuff back to the application.  We end up with two programs
in two different languages running asynchronously and in one
of these programs we have light-weight processes doing things
(again asynchronously) with potential bugs popping up anywhere.
This leads to real fun debugging.  Happily, it is possible to
execute the PostScript through telnet (or psh, which does the
connect to the NeWS server) interactively.  Unhappily the form
that is needed for the C interface will not execute this way
(but can be so transformed relatively(?) easily).  This problem
will undoubtedly be corrected by sun.

The last cloud is mostly political.  It has to do with the
X vs NeWS battle.  NeWS, like X, will succeed to the extent that
it manages to be used, and until there is a generally available
NeWS source, i cant see NeWS being used that extensively.

In summary, I do like NeWS.  I think that NeWS has a clear edge over
other window systems I have seen (i have dealt on one level or another
with Symbolics, Smalltalk, Suntools, and X), but there are problems.
To the extent that these are implementation problems i believe that
sun will do their best to repair them, and if NeWS does get widely
used, i believe that people will build tools that will help.  The
major remaining problem, that of designing applications to use
NeWS well, will be, if not solved, then at least under control, when
people have the experience with NeWS to make more informed design
decisions.

Well, shall we go?  -- jefu (jeff putnam)
Yes, lets go.       -- UUCP: steinmetz!putnam
(They do not move.) -- ARPA: [email-masked] or [email-masked]