PostScript: A Digital Printing Press(computerhistory.org)

    gs -- zmachine.ps calypso.z3

    Date: Tue, 20 Feb 90 15:20:52 PST
    From: [email protected] (Owen Densmore)
    To: [email protected]
    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:

        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.

    -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.

    xnews [PostScript-code]

        bigmac% xnews "1 1 add ="
        2

    /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

    #! /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
    "

    #! /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

    bigmac% ps2bits < $XNEWSHOME/demo/PostScript/tiger.ps > /tmp/bits
    bigmac% bitwin /tmp/bits &

    -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.

    -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.

    createevent dup begin
        /Name   /WUEStatusEvent def
        /Action (/home/project/status/january) def
        /ClientData 1 dict dup begin
            /Completion .70 def
        end def
    end sendevent

    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

    -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!

    -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".

    #! /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
    "