roy@phri.UUCP (Roy Smith) (08/08/88)
As a followup to my recent flamage about the NeWS documentation I
want to point out two specific mistakes, one just ugly and embarrassing,
the other horribly confusing and inexcusable. Both give you the distinct
impression that they were really rushing to push the docs out the door and
didn't have the time to do it right.
1) On page 215 of the "NeWS 1.1 Manual" (the CPS man page), the
description of the -i option reads, "... For example, and would be defined
in the second file." This isn't so bad; once you've puzzled over it for a
minute, it becomes obvious that some text is missing and it's easy enough
to go to the man page source file and see what happened. It looks like
somebody ran the man pages off with the wrong macro package. Not fatal,
but not something I'd be proud to ship to a customer.
2) On page 47 of the "NeWS Application Scenario", the cps source
code is listed for go4.cps. IT'S WRONG! The end of the definition for
draw_board reads "... } for stroke } def" in the manual, but if you go to
the actual file Sun supplies (/usr/NeWS/clientsrc/app_guide/go/go4.cps, you
see:
/draw_board { % - => - (draw the playing surface)
board_color setcolor clippath fill
line_color setcolor
0 1 BOARD_MAX {
dup 0 moveto 0 BOARD_MAX rlineto
0 exch moveto BOARD_MAX 0 rlineto
} for
stroke
pause
} def
Note the "pause" stuck in after the "stroke"! For someone
struggling to figure out how this all works by building an application
based on the examples given, crap like this can really ruin your day (I'm
still trying to figure out which version of the code is the correct one).
Isn't the sample code in the manual imported directly from the working
source files? If yes, then how could a line of code be left out? If no,
then why not?
Hey folks (you NeWS people at Sun are reading this, aren't you?),
I'm sorry if I sound so pissed, but this whole NeWS deal is really making
my opinion of Sun take a nosedive. I know I only paid $100 for the
package, but that's not the point. Before we ordered NeWS, I had a longish
talk with my salescritter about it. The talk went something like this:
Me: Sure, NeWS sounds like the way to go (and the way of the
future) but I'm not interested in playing with a beta test release.
Critter: No, no, no, this isn't beta test.
Me: But I keep hearing about all these various bugs people keep
finding and stuff like that. I'd just as soon wait for the real thing.
Critter: This is the real thing; what we're shipping now is a
production-quality system, with all the wrinkles ironed out, and it's N
(for some random value of N which I can't remember now) times faster than
the 1.0 release.
Sorry Sun, but this just doesn't cut it. The idea is neat, perhaps
even wonderful. But the implementation is slow, buggy, and incomplete
(running dbxtool, for example, under news does work, but it's hardly what
I'd call convenient). The documentation is just as bad; confusing,
incomplete, and in some case, just plain WRONG. The pity of it all is that
all you needed to do to get a happy customer (me) was to tell me all this
when I bought it. If my salescritter had just said told me "yes, it's a
lot better than 1.0, but it's not really production quality yet; that'll be
version 1.2" at least I would have known what I was getting into. Maybe I
wouldn't have bothered, but if I didn't, I certainly would have bought the
next release, and presumably been happy with it because it would have
worked.
--
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"johng@ecrcvax.UUCP (John Gregor) (08/10/88)
In article <3426@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >As a followup to my recent flamage about the NeWS documentation I >want to point out two specific mistakes, Also the entry for 'fork' is missing in my manual. It should be on page 138 next to 'forkunix.' -- John Gregor johng%ecrcvax.UUCP@pyramid.COM
radford@calgary.UUCP (Radford Neal) (08/15/88)
In article <1327@ucsfcca.ucsf.edu>, dick@ccb.ucsf.edu (Dick Karpinski) writes: > The NeWS and the Open Look documentation is said to refer to > the local graphics device as a window server and the distant > applications engine as a window client... > > [ WRONG! ] > > ...The local thing is client. The distant thing is server. This hadn't occurred to me, but you're absolutely right! Furthermore, even the _implementation_ of applications under NeWS might not follow the local "server", remote "client" model. For example, a Postscript process in the workstation might be in control of the application, but make requests to a data-base server on a remote machine. Server/client is a relationship between _processes_. At the relevant level of abstraction, NeWS is not a process. It is virtual machine supporting Postscript processes, some of which might be servers, some clients. While we're at it, the term "host" also seems to be terminally confusing. Radford Neal
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (08/17/88)
In article <1327@ucsfcca.ucsf.edu> dick@ucsfccb.UUCP (Dick Karpinski) writes: > >The NeWS and the Open Look documentation is said to refer to the >local graphics device as a window server and the distant applications >engine as a window client. I am fully aware that this makes good >sense when you understand the mechanism. However, I am acutely aware >that novices find this confusing. > >The local thing is client. The distant thing is server. Don't >confuse me. Don't confuse me with facts or opinions. My workstation >is me or my agent. Distant hosts serve me and my agent. When I need to explain the window server/client relationship, I describe it in terms the user is already familiar with, and which keep things rational and consistent. In economic terms: A server allocates a scarce resource to clients who want access to parts of it. In the case of a supermarket, there are only a finite number of loaves of bread on the shelf and the supermarket manages contention between the customers (clients) who want that bread. They do it by requiring money in exchange, and throttle the demand by maintaining long lines at the checkout counter, among other things. In the case of a file server, the scarce resources are blocks on a disk. Only the server machine has direct access, every client must request portions, and the server doles them out as it sees fit, and scheduling demand between other requests as well as mine. It allocates it fairly by normal request queueing mechanisms at various levels of the protocol stack. In the case of a window server, the scarce resources are the acreage on my screen, and my input devices. There are a finite, countable number of pixels, keys, mice, and mouse buttons available. Screen space and input events are apportioned fairly by algorithms relating to geometry, overlap heirarchies, etc. (Anyone who thinks they know about time-sharing schedulers can handle this.) Once they have this much down, I generalize it yet more and say that the Cray across campus is the cycle server, but my Sun runs the window server. Each needs something the other has in order for the application to run, so each provides the other some of the resources it is uniquely best at providing. When I have to explain what's going on in a server-based window system, I find it much easier to first explain the architecture so that the audience knows just a little bit about what's going on "behind the curtains". Then they have a much better understanding of what they are really trying to do, and my phone doesn't ring with so many questions about incomprehensible error messages, etc. Explain the mechanism to the novice, and {s}he will be happier in the long run. I find this true in most technical fields that I try to explain to novices, not just with window systems. For instance, my wife is a brilliant elementary music teacher, but she never considered herself too hot at "science stuff". She now understands how our airplane flies in terms of compressible flow of air molecules over the wings, and therefore is beginning to understand how and why temperature variations affect wing and engine performance. Then she came full-circle and connected that back to "warming up" an instrument. Don't try to hide the details, if the audience really wants to know! If they build an incorrect mental model too early, it could be very hard to replace it with what's *really* happening later on. >Change the terminology pronto. Please. The terminology has been arrived at through several years of work by lots of folks in the field (not just the authors of the NeWS and Open Look documentation), and is pretty well entrenched. It is even appropriate to describe what's happening. Don't bother trying to change it now. Sorry, I've really strayed from the subject here. Oh well... -=- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@cis.ohio-state.edu or ...!{att,pyramid,killer}!cis.ohio-state.edu!bob
hvr%kimba@Sun.COM (Heather Rose) (08/18/88)
In article <1327@ucsfcca.ucsf.edu> dick@ucsfccb.UUCP (Dick Karpinski) writes: >The NeWS and the Open Look documentation is said to refer to >the local graphics device as a window server and the distant >applications engine as a window client. I am fully aware >that this makes good sense when you understand the mechanism. >However, I am acutely aware that novices find this confusing. You're right. It is confusing. The word "server" has come to mean many things. Even the traditional reference to server has become muddled now that you have an nfs server, a client server, a news server, and a yp server. And on top of that we add the window server and compute server. Seems to me that the word "server" has come to mean a much broader class of items. But in general, it helps to think of the "server" as the one allocating resources. The nfs server gives/gets files to/from the requesting clients. The client server gives disk space via nfs to diskless clients. The news server distributes articles to rn clients to read. The yp server sends and receives password and other networking information to the yp clients. Then the window server allocates realestate on the monitor to client processes and transmits input to the clients and output from the clients to the necessary places. The compute server takes some instructions from the client and delivers the results after the appropriate number of CPU cycles. In general, it helps to think of the server co-habitating with the resources it is allocating. The window server worries about what is displayed on the monitor, so it would live closer to the monitor. The window clients do not necessarily have to do much "window stuff" at all. For instance, say you have a complex expert system working on a mainframe. And now you want to add a wiz-bang UI to it. So, you get Suns to do the UI with the NeWS server running on the Sun and handling user-input and screen output. Then the client of NeWS (the expert system) runs on your mainframe (the compute server). Then the mainframe sends information to the Sun like (give me more data) or (here is my result). The Sun then takes that information to translate it into something meaningful to the user by displaying information on the monitor. I think the field of computer science is running out of words in many areas. Maybe it's time to use latin or greek like medical science has. Then no one would know what anything meant :-) Heather Rose Tech. Support--Windows and Graphics
bzs@encore.UUCP (Barry Shein) (08/21/88)
What's the confusion here? Server: something which provides a resource, such as a piece of hardware. Disk servers provide disks, window servers provide screens. Servers might abstract their resources, NFS makes disks look like file systems, NeWS/X make screens look like window systems. Client: something which uses these resources by indirect requests to the server. Disk clients use other's disks, window clients use other's screens. Servers control the resources (eg. can refuse service, ensure security and integrity in general.) Servers can run w/o clients, clients are meaningless w/o servers and generally just exit(1) immediately or loop looking for them. -Barry Shein, ||Encore||