Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucbvax!BRILLIG.UMD.EDU!don From: don@BRILLIG.UMD.EDU (Don Hopkins) Newsgroups: comp.windows.news Subject: is news loosing the battle? Message-ID: <8807242028.AA24776@brillig.umd.edu> Date: 24 Jul 88 22:24:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 196 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!diamant@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 don@brillig.umd.edu ...!uunet!mimsy!don