Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ichthyosaur.cis.ohio-state.edu!elwell
From: elwell@ichthyosaur.cis.ohio-state.edu (Clayton M. Elwell)
Newsgroups: comp.windows.news
Subject: Re: is news loosing the battle?
Message-ID: <17063@tut.cis.ohio-state.edu>
Date: 6 Jul 88 18:44:31 GMT
References:  <10250002@hpfclp.SDE.HP.COM>
Sender: news@tut.cis.ohio-state.edu
Organization: The Ohio State University Dept of Computer and Information Science
Lines: 103

diamant@hpfclp.SDE.HP.COM (John Diamant) writes:
    Before I begin, let me say that I'm in the X camp myself (I'm an
    experienced X programmer, have seen NeWS and believe I understand
    the basic model, but am not a NeWS programmer, so feel free to
    correct any technical errors regarding NeWS -- which I'm sure you
    would even without an invitation :-)

Well, I'm in the NeWS camp.  I've used X a lot, but for programming
I've been using NeWS (I gave up on X after the third try...).  I
understand X pretty well, although I'm sure you (or, in fact my
coworkers) will correct me if I get confused :-).

    Both NeWS and X have technical advantages, but I don't believe one is
    fundamentally superior to the other.
Well, part of the difference between them, and part of why it's hard
to compare them, is that they are based on very different ideas of
"what a window system should be," and so some of the issues are more
religious than technical.

One, for example, is the whole issue of PostScript.  I actually don't
find PostScript any more obtuse to program in than C, and with the
class system that Sun provides as part of NeWS, doing user-interface
type stuff is in fact a lot easier.  Of course, I also find my HP
calculator perfectly easy to use :-).

    Now, let's examine the NeWS advantages for a moment and see how
    important they are.  Regarding the imaging model, it is only 2D,
    and X is getting the 3D graphics extensions defined as a standard
    extensions, [...]
I think this a straw man argument.

Most workstation displays I've seen are 2D...  Yeah, you can add
3D rendering primitives to X, but I can add 3D rendering operators to
NeWS, without (a) having to touch my binaries or (b) making
assumptions about the display itself.  If I'm a vendor, I can even
hack my version of the server to do it in hardware.

    Non-rectangular windows is "gee whiz," but frankly, I don't care
    about that at all.
Well, it's not just windows.  Anything can be non-rectangular.  Like
buttons and controls.  I agree that rectangular ones are good enough
for most simple interfaces, but it's nice to have the generality there
when you need it.
    
    Postscript will be available on X as well, thanks to Display
    Postscript and some public Postscript previewers.
And Display PostScript is evidently very nice and fast.  However,
previewing PostScript documents is a small portion of what I do with
my workstation.  PostScript itself isn't so much the issue as having a
well-defined way to extend the capabilities of the display server, on
the fly if necessary.  The simplest way to do this is to pick a simple
language with good graphics primitives.  Add popular to the
requirement, and PostScript seems the logical choice to me.  I'd
rather that than Interpress or HPGL :-).
    
    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).
Of course, dynamic loading is done differently on every flavor of
UNIX, so the client support routines have to be kept up to date.  With
NeWS, all you have to do is be able to talk to your display, which is
kind of a given.

    Probably the most significant difference between X and NeWS is the
    traffic between client and server.  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).
Well, in most of the programs I've seen, most menu choices either
*don't send anything back to the client at all*, or send a byte as
part of the input stream.  Seems pretty low overhead to me.  But
that's probably not a good example.

    Second of all, it doesn't really matter!
I like that--the most significant difference doesn't really matter!  

    The only time this will really matter is for non-local lans, like
    SLIP remote links or over low-speed remote channels.
Which, of course, nobody ever really uses...  Take the ARPAnet, for
example... :-).

    Basically, the assumptions that X used were that a high-speed byte
    stream was available between client and server and that the client
    was a more powerful machine than the display server.  NeWS uses a
    different set of assumptions (or at least it shines in a different
    environment).
I'd say that NeWS is based on the display server knowing about the
details of the display hardware, so that the client didn't have to
worry about it, and that abstraction is a good thing.  X is one of the
least abstract systems I've ever used.  I like Bill Joy's
description--"rasterop on wheels".  I like PostScript on a window
system for the same reason I like it on a printer or a typesetter.
Most of the time, I don't want to have to worry about how to chisel
bits onto the screen.  I realize that things like Xtk and so on help,
but still, it's a virtual display at a lower level than I care to deal
with.


Clayton M. Elwell 
Ohio State University CIS Dept. Research Computing Facility

"... there was a *third* possibility that we hadn't even counted
upon ..."		--Arlo Guthrie, "Alice's Restaurant"