19 ms·

Sun's NeWS was a mistake, as are all toolkit-in-server windowing systems (2013)

• ggm 7y ago
  It could have been JavaScript 10 years before we had JavaScript. It demanded more dedication to use. Turns out round window with stroke path text alpha and reimplemented xeyes was not compelling. People should have shown NeWS doing complex client side form field checks. Sun also didn't go downmarket. Windows PCs happened with hummingbird xceed X not decent in Microsoft X
  • DanielKehoe 7y ago
    Every day that I program in JavaScript I wish we had Display Postscript or NeWS in the web browser. Imagine if browsers had evolved with Postscript instead of JavaScript.
    • masswerk 7y ago
      However, fashions in languages are a thing. While PostScript was hot by the mid 1980s, few were using it 10 years later, as there were now WYSIWYG PostScript editors like Illustrater, XPress, Page Maker, etc. Now, these were the days of C(++) and Perl, as may be observed in the JS syntax. But it would have been nice, if it had started with ECMA script (as opposed to LiveScript) and SVG had been already around.
    • deleted 7y ago
      [deleted]
    • tonyedgecombe 7y ago
      Imagine if browsers had evolved with Postscript instead of JavaScript. Adobe would have a stranglehold on the market instead of Google.
    • mhd 7y ago
      It's not PostScript instead of JavaScript. It's PostScript instead of HTML, JavaScript and CSS. That's (IMHO) the more important point. One programming language to write and structure everything instead of a bastardized SGML plus a bastardized Java plus an ad-hoc config add-on. I'd much rather have (a slightly saner) JS for everything than PostScript plus HTML plus CSS, if I would have to choose.
      • ptx 7y ago
        Netscape 4 actually had JavaScript-based stylesheets, before everyone settled on the CSS standard: https://en.wikipedia.org/wiki/JavaScript_Style_Sheets https://en.wikipedia.org/wiki/JavaScript_Style_Sheets
        • mhd 7y ago
          Neat, I wasn't aware of that. Ah, the things that could've been.
• RajuVarghese 7y ago
  It may have been a mistake but it did add an important innovation: Postscript in the display system. This would be an innovation even now, having an interpreter for an embedded language right in the windowing system.
  • cpach 7y ago
    AFAICT Apple does something similar in Quartz…? https://en.m.wikipedia.org/wiki/Quartz_(graphics_layer) https://en.m.wikipedia.org/wiki/Quartz_(graphics_layer)
    • DanielKehoe 7y ago
      NeWS (developed at Sun) and Display Postscript (developed at NeXT) were each adaptations of Postscript to the screen. Apple (after the NeXT takeover) developed Quartz to avoid paying licensing fees to Adobe for Display Postscript. So yes, Quartz does something similar to NeWS.
      • setpatchaddress 7y ago
        Two corrections: - Adobe was uninterested in supporting Display PostScript by 1997. The cost was secondary. - Quartz / Core Graphics is based on the PDF rendering model, which is derived from PostScript. You use C graphics routines to draw; there is no programming language.
    • fulafel 7y ago
      There are similarities in the rendering model but the big thing of uploading code is no there. But of course we now have GPU shading languages..
    • rodgerd 7y ago
      Which brings us to the silliest part of the post: the idea that X won, or proved much of anything at all. X is basically noise in the computing world: the atrophied stump of the ix GUI market. The most popular Unix-like OS in the world is rooted in display PostScript. The most popular OS with a Linux kernel doesn't use X, or indeed a *ix-like userland.
• paol 7y ago
  I believe X Windows owes much of its incredible longevity to the "provide mechanism not policy" mantra that its designers took very seriously. Having the toolkit in the server would necessarily force it to define and enforce lots of policy. This increases complexity, increases dependency (coupling) on part of the clients, and after all that you still have the problem that policy simply doesn't age well. It still boggles my mind a bit that a display stack designed in the 1980s has remained viable to this day. Sure, it's a patchwork, and it's finally being replaced, but it works.
  • pjc50 7y ago
    The WinForms API also survives from the mid 80s, and is interestingly different. I believe the classic controls were originally drawn in the kernel?
    • codeflo 7y ago
      You probably mean Win16/Win32, not WinForms. But it only survives in the sense that it’s still there, not in the sense that it’s still useful. How many applications created in the last five years use Win32 for anything but creating a top-level window (usually via Chromium/Electron)?
      • my123 7y ago
        > How many applications created in the last five years use Win32 for anything but creating a top-level window (usually via Chromium/Electron)? I think that you're in a bubble for that one. Many business domain-specific applications are still directly written against Win32 even today. UWP didn't manage to catch up for now either. Electron usage is mostly only in startup-y apps and some IDEs.
        • codeflo 7y ago
          No experience is universal, so I'm curious in what industry you encounter Win32. Or do you mean WinForms? I often work with industrial manufacturing companies in Europe, with a mindset about as far from that of Silicon Valley startups as you can imagine. You usually won't find Electron there. Many "legacy" projects are in WinForms. But for newer stuff, I see lots of WPF and Qt projects, both of which don't use native controls.
• nibbula 7y ago
  Although I admire and frequently agree with this blog, I think this article exhibits some common misconceptions about NeWS. NeWS had what amounted to uploadable toolkits, and therefore could and did have multiple toolkits. A client could decide how it wanted to separate processing between the client and server, which seems truly more flexible and allows for much more efficient communication. Also NeWS had threads which if done today would certainly use multiple processors. Clients could, but didn't have to, use a separate address space and language even. But the graphics API was so much better, it's ridiculous, and is basically the same as now in SVG, html canvas, and most other decent things. The big drawbacks of NeWS in my opinion are not having an MIT license, and being quite difficult to implement well. Also PostScript isn't the nicest language to program in, which I say from years of programming in it. But it's far from the worst, and if one changed the to postfix syntax to prefix, it would be mostly a Lisp.
  • kick 7y ago
    What do you not like about PostScript? It's basically a worse Forth, which, when compared to most languages, is comparatively wonderful to write in.
    • triska 7y ago
      How is PostScript a "worse Forth"? I find PostScript great fun to program in, and I think the type errors one gets from the system to indicate mistakes are a great help when writing PostScript code.
      • kick 7y ago
        It's much higher level, chooses the worst bits of high-level languages to throw in, NeWS's spin of it was object-oriented which has since been shown to be a mistake, it's not as extensible, has too many stacks, introduces significant complexity for dubious benefit, so forth. Of course, whether or not PostScript is like Forth at all is a matter of debate, some religiously disagree. I'm somewhere in the middle on that. Old flamewar topic: http://wiki.c2.com/?ForthPostscriptRelationship http://wiki.c2.com/?ForthPostscriptRelationship The syntax is also slightly less nice, which is relevant for their question, but less quantifiable.
• sprash 7y ago
  > In the increasingly multi-core world you desperately want as much concurrent processing as possible and it's much easier to run several clients in parallel than it is to parallelize a single server. There is nothing more multi-core than a modern GPU. Actually the existence of modern GPUs is an argument FOR toolkit-in-server windowing systems. All you do is writing shaders that help you to keep the communication over the PCIe bus (and potentially network, if you want network transparency) as minimal as possible. The NeWS system failed for none of the reasons described in the article. It failed because of bad performance. There never was custom silicon out there to render Postscript. Unlike today where you have vastly underused GPUs at your disposable just waiting to be stuffed with intelligence in form of shaders. Just have a look at https://shadertoy.com https://shadertoy.com to see what is possible even on low-end GPUs. Edit: as cpach pointed out shadertoy.com and not .org
  • cpach 7y ago
    I think you meant shadertoy.com, right? :)
  • fulafel 7y ago
    In modern graphics applications (=games) people do try to reduce CPU-GPU communication, but it is still done a lot and is frequently a bottleneck. Increasing GPGPU work means CPU and GPU code communicate in both directions. Making it slower than it already is doesn't make sense from performance engineering POV unless there are some dramatic advantages from the tradeoff.
    • sprash 7y ago
      > Increasing GPGPU work means CPU and GPU code communicate in both directions. Only if you make the wrong abstractions. Using a shader based toolkit is not about increasing the GPGPU work but to use the GPU for things that it is intended to do namely drawing. And if you make the right abstractions you can severely reduce CPU-GPU communications. In fact a toolkit is exactly the perfect type of abstraction in that scenario. Most of the input is mouse and keyboard data and a bunch of drawing commands which means extremely low bandwidth, less CPU-GPU communication, more performance and faster applications. I'm not sure what you mean by "tradeoff". Look for example at the shaders of sahdertoy. For the most part the only data they receive from the CPU is a timestamp of the current frame and occasionally mouse and keyboard data which is in the worst case literally just a bunch of bytes per frame.
• radiator 7y ago
  To my eyes, NeWS does not look like a mistake. On the contrary, it looks beautifully engineered. Among other advantages, I can imagine a world where PostScript would be used for building user interfaces: a document in screen and print would look the same, without need for writing conversions like, e.g. HTML+SVG -> PDF when someone needs to somehow print a web form quickly. And perhaps the old principles of typography and the experience in typesetting beautiful books with PostScript could be more easily applied to UI design.
  • crooked-v 7y ago
    > a document in screen and print would look the same This only works if all the screens are the same size as a sheet of paper.
    • japanoise 7y ago
      And have the same dpi as whatever's used to print them!
      • basementcat 7y ago
        I can print the same PS file to different printers (inkjet, laser, dot matrix) and (subject to resolution constraints) obtain similar documents from each device.
    • triska 7y ago
      A key advantage of PostScript is that you can scale all output using transformations, so that you internally work with the same coordinate space (called user space) on all devices, and implicitly scale — and also for example rotate — all graphics when they are actually drawn. This extends to fonts too, since PostScript letters are drawn using the same graphic primitives as other graphs.
      • arethuza 7y ago
        I worked on a project in the early 1990s where we used the utterly wonderful HyperNeWS for most things - we used to play tricks on each other by doing silly things like logging into someone else's NeWS server using psh and setting the rotation in the transforms for a terminal window to be slightly off as people were using them - eventually people would notice of course but things would just work. Another neat trick that HyperNeWS supported was drawing a shape in its graphical editor and then pasting that shape as the shape of a window...
• fulafel 7y ago
  Picking parallelization of clients as the #1 reason seems like a miss to me. X never took advantage of it much. The asynchronity in X was motivated by network latency.
  • deleted 7y ago
    [deleted]
• GeorgeRichard 7y ago
  "One of the great white hopes of the part of the Unix world that never liked X Windows was Sun's NeWS." I searched Wikipedia and found that "Great White Hope is a nickname or epithet originally applied to boxers who were the hope of the "White Race" to beat African American boxer Jack Johnson." That seems an odd way to characterize the situation.
  • kick 7y ago
    "great white hope" is an English idiom. While originally having racist connotations, it's entered common usage and is no longer tied to racism, or anything in particular.
  • projektfu 7y ago
    It makes sense when you consider that white people were wringing their hands because they were convinced of their total superiority. While obviously more benign, there is inherent bigotry in the “X sucks and the better solution is Y or Z and why won’t they catch on?” mindset. Surely this next technology will take over from the unacceptable popular one. (Edited because QuickPath has a long way to go before it’s as functional as Swype)
    • DonHopkins 7y ago
      Actually, the predecessor to X was called W. And many people have proposed the next version of X should be called Y, because X12 wasn't different enough, and some even have suggested skipping Y and going directly to Z to get even more distance from X. But the one thing they all agree on is that X sucks.
      • projektfu 7y ago
        I was using X in the sense of a variable, sorry.
• tinus_hn 7y ago
  From what I remember the choices were NeWS and it only runs on Sun hardware, or X and it runs everywhere. Ultimately Sun no longer had enough advantages to compensate for their half compatibility, shipping incompatible ancient compilers and out of date libraries.
• DonHopkins 7y ago
  https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently: - used PostScript code instead of JavaScript for programming. - used PostScript graphics instead of DHTML and CSS for rendering. - used PostScript data instead of XML and JSON for data representation. FTFY: Web Browsers were a mistake, as are all toolkit-in-browser JavaScript libraries April 1, 2020 One of the great white hopes of the part of the Web world that never liked Gopher was Netscape's web browser. Never mind all of its practical flaws, all sorts of people held web browsers up as the better way and the bright future that could have been if only things had been different (by which they mean if people had made the 'right' choice instead of settling for Gopher). One of the reasons people often give for liking web browsers is that it put much of the JavaScript libraries into the web browser instead of forcing every server to implement it separately. Unfortunately for all of these people, history has fairly conclusively shown that web browser was a mistake. Specifically the core design of putting as much intelligence as possible into the web browser instead of the web server has turned out to be a terrible idea. There are at least two big reasons for this. The first is parallelization. In the increasingly multi-core world you desperately want as much concurrent processing as possible and it's much easier to run several web servers in parallel than it is to parallelize a single web browser. Even if you do get equal parallelization, separate web servers are inherently more resilient because the operating system intrinsically imposes a strong separation of address space and so on, something that's very hard to get in server where everything is jumbled together. (I believe that this is one reason that modern HTML CSS rendering has been moved from the web browser to the web server. WebFont rendering is increasingly complex and CPU-consuming, so it's better to stick web servers with that burden than dump all of it on the web browser. After all, all Web Servers should have multiple GPUs for drawing and accelerating graphics and numeric computing for all their clients, but there is no rational reason anyone would ever want to program the GPU in the web browser, or push that processing off from the honking big accelerated server farms that you're renting from Amazon by the minute, to the millions of web browsers run by your users whose electricity you don't need to pay for. Plus, users enjoy waiting for their graphics to download over the internet in response to every mouse click and movement they make. It gives them time to think and reflect.) The second is that if you put the toolkit in the web browser you make evolving the toolkit and its API much more complicated and problematic. The drawback of having everyone use the web browser toolkit is that everyone has to use the same web browser toolkit. Well, not completely. You can introduce a mechanism to have multiple toolkit versions and APIs all in the same web browser and allow web servers to select which one they want or need and so on and so forth. The mess of a situation with the current web browser and its JavaScript libraries make a very educational example of what happens if you go down this path; not very much of it is good. (Some JavaScript libraries are in practice mandatory but still must be probed for and negotiated by the web servers, while others are basically historical relics but they still can't be dropped because some web server somewhere may ask for them.) JavaScript libraries in the web browser push the burden of dealing with the evolution of the library into the web server. It is the CDN and web browser cache that carries around old or new versions of the library, with various different APIs, and you naturally have old library versions (and even old toolkits) go away entirely when they are no longer used by any active web servers (or even any installed web servers, when things get far enough). (I'm ignoring potential security issues for complex reasons, but they may be a good third reason to be unhappy with browser-side libraries.)
• pjmlp 7y ago
  Not at all, alongside NeXTSTEP, it made UNIX actually interesting as workstation OS.
• DonHopkins 7y ago
  Owen Densmore recounted John Warnock's idea that PostScript was actually a "linguistic motherboard". (This was part of a discussion with Owen about NeFS, which was a proposal for the next version of NFS to run a PostScript interpreter in the kernel. More about that here:) https://news.ycombinator.com/item?id=17077721 https://news.ycombinator.com/item?id=17077721 Owen Densmore's discussion of John Warnock's "Linguistic Motherboard" idea for PostScript: https://donhopkins.com/home/archive/NeWS/linguistic-motherboard-owen.txt https://donhopkins.com/home/archive/NeWS/linguistic-motherbo... Date: Tue, 20 Feb 90 15:20:52 PST From: owen@Sun.COM (Owen Densmore) To: don@cs.UMD.EDU Subject: Re: NeFS > They changed the meaning of some of the standard PostScript operators, > like read and write, which I don't think was a good idea, for several > reasons... They should have used different names, or at least made .. Agreed. And I DO see reasons for the old operators. They could be optimized as a local cache for NeFS to use in its own calcs. > Basically, NeFS is a *particular* application of an abstraction of > NeWS. The abstract idea is that of having a server with a dynamically > extensible interpreter as an interface to whatever library or resource > you want to make available over the network (let's call it a generic > Ne* server). Very true. This has been particularly difficult for me to get across to others here at Sun. I recently wrote it up for Steve MacKay and include it at the end of the message. > It's not clear to me if NeFS supports multiple light weight PostScript > processes like NeWS. I asked Brent about this, and he agreed that it's an issue. Brent has been talking to a guy here who's interested in re-writing the NeWS interpreter to be much easier to program and debug. I'd love to see them come up with a NeWS Core that could be used as a generic NetWare core. I think you should send your comments off to nfs3 & see what happens! I agree with most of your points. Owen Here's the memo I consed up for MacKay: ====================================================================== Window System? ..NeWS ain' no stinkin' Window System! -or- Swiss Army NeWS: A Programmable Network Facility ====================================================================== Introduction NeWS is difficult to understand simply because it is not just a window system. It is a "Swiss Army Knife" containing several components, some of which contribute to its use as a window system, others which provide the networking facilities for implementing the client-server model, all embedded in a programmable substrate allowing extremely flexible and creative combination of these elements. During the initial implementation phase of the Macintosh LaserWriter software, I temporarily transfered from Apple to Adobe working closely with John Warnock and other Adobe engineers. At lunch one day, I asked: "John, what do you plan to do after LaserWriter?" His answer was interesting: PostScript is a linguistic "mother board", which has "slots" for several "cards". The first card we (Adobe) built was a graphics card. We're considering other cards. In particular, we've thought about other network services, such as a file server card. He went on to say how a programmable network was really his goal, and that the printing work was just the first component. His mentioning using PostScript for a file server is particularly interesting: Sun's next version of NFS is going to use PostScript with file extentions as the client-server protocol! This paper explores NeWS in this light: as a Programmable Network Facility, a major part of Sun's future networking strategy. NeWS Networking Components NeWS has realized John's notion of a programmable network facility. It has populated the initial PostScript mother board with several cards vital to netwoking: -Device Independent Graphics Primitives: The key importance of the PostScript graphics model for networking is that it is device independent, able to represent with one file the same drawing on *all* the network hosts. The Folio fonts contribute to this: they can be rendered at a given point size on all screens, regardless of resolution. -Host Independent Interpreter: PostScript is an interpreted language that runs on all Sun workstations without recompilation. The significance of this for networking is that small code fragments can run on any host without any knowledge of the host's architecture. Thus one host sending a code fragment to another host need not be concerned whether that host is a Sun-3, Sun-4, or even Macintosh! This extends to client programming languages as well: all client languages have the same interface to the host. As an illustration of this point, both C and Lisp clients use the TNT toolkit with no special interfaces for each language. -Network Socket Primitives: NeWS has added primitives for listening for connection requests, for socket files, for host name and internet number management, and for reading and writing on the network connection. In fact, the NeWS "server" code is not written in C, it is written in PostScript. The initial version, and the one I run on my own machine today, is 10 lines of code! -Light Weight Processes (LWP): A network host has many independent activities taking place at one time. Each of these uses a separate LWP. These activities need not be window oriented, and in fact most are not. Consider WUE alarms, for example. A LWP could be created on each WUE NetStation whose only task was to listen for activities on other WUE NetStations and to cause a WUE Alarm to occur when an interesting event occurs. -Garbage Collection: When data is allocated within NeWS, it is returned to the free memory pool when no process references it. This is needed in a multiprocessing network host because separate LWPs can reference the same shared data. (No process can safely free data itself, because other processes might reference it.) Garbage collection manages this problem for the processes, and thus is an important Network facility. -Programmable Events: NeWS has a flexible, very easy to use event management scheme. Processes fill out templates of events they are interested in. When these are matched by events occuring within the system, they are delivered to the interested process. Events are *far* more useful than simple keyboard and mouse events. They can be artificially manufactured for any sort of inter-LWP communication. For the previous WUE Alarm, for example, the WUE "Listening" process would communicate to WUE-Friendly applications by filling out a WUEAlarmEvent and sending it. The interested applications would have filled out a template which would "catch" the event. -Programmable Error Handling: NeWS uses the standard PostScript exception handling, extended to work within the context of LWPs. Thus an error in one LWP is isolated to that process only. Network programs can "wrap" incomming code inside of the special "stopped" error handler which will catch errors occuring inside the code fragment. This is vital to safe network programming. What IS NeWS Anyway! "Well, I'm glad NeWS has all these useful parts, but just what IS NeWS anyway; how do I get at and use all this stuff." Well you may ask! It does seem confusing. Formally, NeWS is simply a Unix command, just like "ls" and "cd". Its syntax is: xnews [PostScript-code] i.e. it is a command that executes PostScript code fragment. If the xnews command is given without an explicit argument, it defaults to executing "(NeWS/init.ps) run", which simply looks for the file "init.ps" in the "$OPENWINHOME/etc/NeWS" directory. It is this file that uses the NeWS components to setup the X11/NeWS window system. As a silly example of handing in your own commands to NeWS, we can do this: bigmac% xnews "1 1 add =" 2 This simply tells xnews to add 1 & 1 and print the results. Oddly enough, I have written a somewhat more complex script to fill out my Traval Advance forms, adding up all the rows and columns and printing out a version of the form! Now that we've gotten though the fundamentals, the rest of the paper will look at individual examples of using NeWS in novel ways. Although we present programs to illustrate how things are done, the reader may skip over them, the accompaning text will explain what the program does. The Ten-Line Server As mentioned above, "xnews" is simply a Unix command that executes a PostScript program, defaulting to "(NeWS/init.ps) run". Init.ps performs several initialization tasks and executes the commands in various other files. When its done with all of that, it defines and executes a small procedure called "server". This program uses the NeWS networking facilities to build a LWP which listens for connection requests from "client" programs. Whenever a request is heard, the LWP awakens and creates and initializes a new LWP just for the client's usage. Here's the ten line version of the server. This actually works (I've run it for quite some time!), and is explained in Chapter 10, Networking NeWS, of the Unix Networking book published last year. /server { % - => -; create the NeWS client-server listner process { clear newprocessgroup % -; Clean stack, init process group (%socketl2000) (r) file % soc; Open socket for listening { dup acceptconnection % soc f;Loop forever creating clients { exch pop 200 dict begin % f; Create userdict initmatrix newprocessgroup % f; Init graphics & process cvx exec % -; Execute the connection! currentprocess killprocessgroup%Cleanup client & children } fork pop pop % soc; Clear process & file } loop % soc; Loop forever creating clients } fork pop % -; Fork server & toss process } def The significance of this is that we can just as easily build other network services with NeWS, using code much the same as the above. NeWSPrint, for example, uses a similar PostScript program to provide network printing facilities. NeWSPrint does not require a special, modified version of xnews; it simply uses the standard OpenWindows product. ps2bits: A PostScript to Rasterfile Program A second use of running xnews as a Unix filter is illustrated by the ps2bits probram. This Bourne shell script reads a PostScript file on its "standard in", and emits the resulting Sun raster file on its "standard out". The shell script does this by having xnews: -Read in a few standard PostScript initialization files, -Initialize the PostScript environment (& fix a Folio bug!) -Build an 8.5 by 11, color, 72 dpi resolution "page" canvas -Execute the PostScript stdin file to draw that page -Write the resulting image to stdout as a raster file Here is the program: #! /bin/sh xnews " (NeWS/pack.ps) (r) file cvx exec (NeWS/basics.ps) (r) file cvx exec (NeWS/redbook.ps) (r) file cvx exec 500 dict begin false setautobind () stringwidth pop pop 612 792 8 [1 0 0 -1 0 792] null buildimage setcanvas (%stdin) run clippath (%stdout) (w) file writecanvas " Note: The line with the "buildimage" command may be modified to convert the program to black & white, or to change the resolution to 300 dpi, or to change the page size. See Appendix A for a more general script. Once the image is made, it can easily be looked at in SunView, XView, or NeWS using any of their raster file viewers. Here's a trivial viewer, "bitwin", using the TNT toolkit: #! /bin/sh psh <<BITS /win [ClassCanvas] [] framebuffer /new OpenLookBaseFrame send def { clippath pathbbox scale pop pop (${1}) readcanvas imagecanvas } /setpaintproc /client win send send (${1}) /setlabel win send 100 100 425 550 /reshape win send /activate win send /map win send BITS This Bourne shell script takes a single command line argument naming the raster file. It uses the NeWS "PShell" to sent a short program to the running xnews server. The program will put the file name in its header, and will fill itself with the raster file image. Stretching the window will stretch the image. To use these on the demo file "tiger.ps" which was initially created on the Mac using Adobe Illustrator, these two steps are taken: bigmac% ps2bits < $XNEWSHOME/demo/PostScript/tiger.ps > /tmp/bits bigmac% bitwin /tmp/bits & The first command converts the tiger drawing into a raster file. The second creates a window for viewing the raster file. Although the complexity has been fairly minor in the previous examples, we've illustrated some powerful capabilities: -We can easily use NeWS to provide a simple Unix facility for converting PostScript drawings into Sun raster files. The PostScript may come from any of the many widely available sources, even the Macintosh. -These raster files can be used by any toolkit, including SunView. They can even be used by other raster devices such as printers. -Using the networking primitives used in the 10-line server, we could easily build a similar server for providing raster files to anyone on the network. Using these NeWS facilities in similar creative ways is exactly what NeWSPrint does. The documentation folks use a similar "filter" to strip out all the general header information in Mac PostScript files to gain an average 8-1 compression, vastly reducing their disk storage requirements. A homework assignment in our Usenix NeWS tutorial is to create a generalized Image Server for the network using these facilities. WUE Alarms with Programmable Events WUE has the notion of "alarms" which can be used to alert applications of changes in status of network objects. Applications can use this for anything from "hot links" to file status alarms. One of the WUE examples is on file status: I want to know when the monthy report reaches 90% completion. Hot links are similar: I want this graph to change whenever the associated spreadsheet changes. Here is one way to implement WUE file alarms using NeWS programmable events: -WUE provides a Property Sheet which includes a file completion field holding a percentage quantity. -When the Property Sheet is completed, it creates and sends a WUEStatusEvent for the given file. The network name of the object is stored in the event's Action field. The event includes auxillary information about the file in the ClientData of the event. -Applications following WUE object status changes use the NeWS "expressinterest" primitive to catch all WUEStatusEvent's for the desired file. It then looks at the ClientData to determine whether or not further action should be taken. The WUE Property Sheet would build and send the event this way: createevent dup begin /Name /WUEStatusEvent def /Action (/home/project/status/january) def /ClientData 1 dict dup begin /Completion .70 def end def end sendevent The application builds an interest for its TNT event manager to handle. It does so by building a matching event template for WUEStatusEvent and the /home/project/status/january filename. It also includes a "callback" procedure which decides what to do with the completion information. In this case, we want the alarm to occur when the file is more than 90% complete: createevent dup begin /Name 1 dict dup begin /WUEStatusEvent { % event => -; check if complete yet /ClientData get /Completion get .90 ge { AlertApplication } if } def end def /Action (/home/project/status/january) def end MyEventMgr expressinterest This results in the AlertApplication procedure being called when the /home/project/status/january report is within 10% of completion. Puny WOF (Workgroup Object Facility) The above alerting works only for applications running on the same workstation. This is because the event that is sent is only visible to interests expressed on the same workstation. We can easily extend our model to include sending the event to many network workstations by using the same techniques as the 10-line server: -WUE friendly workstations start a WUE event listening service when they start up NeWS. This uses exactly the same techniques as the 10-line server, but using a different socket file. They also regester themselves with a centralized list of WUE friendly workstations. -The WUE event listening service starts a second process which expresses interest in all local WUE events. When any WUE event is caught, it is "forwarded" to each of the workstations listed in the central list. It does this by opening a socket file to each workstation, and sending a small program down the socket which sends the WUE event on the remote machine. -The Property Sheet sends the WUEStatusEvent exactly as before. Local applications running on the same machine operate exactly as before. In addition, however, the local WUE event forwarder causes the same event to be sent on each of the regestered workstations. Applications on those machines would now catch the forwarded event exactly as if it were local. The application need not be modifed! This basically implements a Puny WOF (Workgroup Object Facility). And it can be done very easily indeed! Admittedly that this is quite puny and many details about robustness etc. have to be managed. On the other hand, using xnews as a WOF prototyper is extremely appealing. (I plan to prototype a versions of Puny WOF as soon as I get a second host set up and running in my office.) Multi-Media: NeWS Device Control Multi-media devices can be managed by NeWS, using programmable events to interface to applications. This provides a logical division between the device "driver", which may be implemented in any of several ways, and the application API to the device, which is via NeWS events. As an example, consider a graphics tablet input device with an RS232 interface. This device emits x,y data in a well-known format to the serial device when the tablet's stylus moves. As an initial implementation, the driver half of the device was written in PostScript as a process which opens and reads the file /dev/tty. When there is no data on the device, the process blocks, pausing until data arives for the device. When the data arives, the read returns with the device data. This is packaged into an event as in the WUE Alarm example. Typically the device data needs processing that is better suited to C programming. The solution is to rewrite the device manipulation as a NeWS client using either CPS or the TNT Wire Service. The application interface, however, continues to be the same event interface. The improved performance incurrs no change in the application interface. The notion of this variety of client "daemon" has been used in TNT for providing shared text service among applicaions. A voice interface to EMacs was also made in AD using the same technique. Another significant advantage to this division of labor into a device layer using an event interface to applications is that it gracefully evolves into sharing the single device among multiple applications. The device is temporarily "owned" by one application, and is given to another application using an agreed upon protocol. Two common styles are used: -The keyboard uses a "focus" model where certain UI events not associated with the keyboard determine which application owns it. -The mouse is typically owned by the application in which it was last "clicked". In the case of the graphics tablet, applications wanting to use the tablet would express interest in the tablet's button being clicked within it. From then on, that application will receive the motion change events for the tablet. Although device ownership may seem like a trivial problem, fairly complex systems are typically needed to solve it for a given device. The VOX server from Olivetti for voice is used for just this kind of thing: negociation between applications for ownership of the voice device. Because VOX is not integrated into a more general event system, however, it cannot manage the user interface for which application currently owns it. It can only provide the regestry. When OpenLook defines the "focus" model for ownership of the voice device, a NeWS oriented voice service will much more easily integrate into the rest of the system. Just as WUE Alarms had a network component, certain multi-media devices will be expensive enough to warrent sharing on the network. Scanners and fax machines will be attached to individual machnes, but we may want them to be temporarily owned by other workstations. The same "server" technology used by the 10-line server and the Puny WOF can also be used here. Summary and Vision The interesting software architectures of the next decade will leverage network technologies. We will see WUE become the Net Finder, replacing the simplistic Mac Finder in the network intensive workstation world. WUE will manage network resources among WUE-Friendly NetStations, workstations with advanced, easily configured network software platforms. NeWS is such a network tool: a programmable network facility. Another is the newly proposed NFS which uses file server extended PostScript as its client-server language. We hear far too many NeWS vs. X arguments based on window and UI toolkit arguments alone. These, in my opinion, miss the main strengths of NeWS. It is a programmable network facility which can be used for many purposes. It can prototype new network services. It can be a universal device controler. It can be used to integrate multiple hosts. All these elements also need to be evaluated when considering NeWS. References [1] PostScript Language Reference Manual, Adobe Systems, Addison Wesley, 1985 [2] The NeWS Book, Gosling & Rosenthal, Springer-Verlag, 1989 [3] Unix Networking-ch 10: Networking NeWS, Owen Densmore, Hayden Books, 1989 [4] NFS-3 Design Document, Brent Calaghan, Sun internal document, 1990 Appendix A: A more general ps2bits shell script. #! /bin/sh # Parse cmd line args: ps2bits [-size W H] [-dpi X Y] [-color] X=72; Y=72; W=8.5; H=11; Z=1 while [ ${#} -gt 0 ]; do case "${1}" in -dpi) shift; X=${1}; shift; Y=${1} ;; -size) shift; W=${1}; shift; H=${1} ;; -color) Z=8 ;; esac; shift done # Run NeWS as Unix filter. Note use of Bourne shell variables! xnews " (NeWS/pack.ps) (r) file cvx exec (NeWS/basics.ps) (r) file cvx exec (NeWS/redbook.ps) (r) file cvx exec 500 dict begin false setautobind () stringwidth pop pop $X $W mul $Y $H mul $Z [$X 72 div 0 0 $Y -72 div 0 $H] null buildimage setcanvas (%stdin) run clippath (%stdout) (w) file writecanvas "
• carapace 7y ago
  Reminds me of the classic "Wheel of Reincarnation" paper: "On the Design of Display Processors" http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-display-processors.pdf http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland... (Good work getting traction on this kick! ;-) I'm kind of dealing with something like this now myself. I have an implementation in Prolog of a Forth-like language called Joy and I want to make a GUI for it that might actually be used by normal people. I could use e.g. SDL and draw everything myself and handle mouse events etc. (I have a crude demo in PyGame that does that.) Or I could use some sort of widget toolkit (I've got a Tkinter demo too.) Or I can use the browser and treat it like a smart display processor. There are editors and spreadsheets and libs and all kinds of stuff. The Prolog/Joy code can stay nice and high-level, with HTML and CSS as the "display language". - - - - Which brings me to my main point: How in the heck is this not more nailed down in 2020!? I first wrote a DSL for GUI layout in the late 90's, I used Delphi was even earlier, and I known that's all late to the party: we could go back to The Mother of All Demos or even earlier. The mouse and hi-res raster displays and GUIs are old but usage is nowhere near settled yet. Is that because the domain is really so intricate and challenging or are we just milling around and mistaking it for progress? Whither React? (By which I mean maybe functional reactive programming or better yet Kowalski's Logic Production Systems (LPS http://lps.doc.ic.ac.uk/ http://lps.doc.ic.ac.uk/ ) might finally start to reduce the churn and nail things down.) ( https://en.wikipedia.org/wiki/Delphi_%28IDE%29 https://en.wikipedia.org/wiki/Delphi_%28IDE%29 )
• mwfunk 7y ago
  "X Windows"