bzs@bu-cs.BU.EDU (Barry Shein) (07/07/88)
Hi, my name is Barry Shein and I am an alc...no, that's not right... I am not and never have been a card carrying member of...ummm, one more time... I'm trying to be very open-minded on the X/NeWS issue. This means I've probably pissed off both camps sufficiently and they are each quite sure I lean the other way, as religions are wont to do (see for example the writings of Cardinal Newman, "one cannot be both a believer and questioner"), relgions are usually more open to identifying heretics than observants... First, I have vastly more experience with X than NeWS tho I don't think I misunderstand NeWS, I think I get the point. I am very sensitive to the "imaging model" issue. One of the first things anyone attempting to write a toolbox in X runs into (at least any honest person) is the whole issue of pixel sizes and relative metrics, particularly with fonts, big problem with X, claims of "portability" seem to slip away when they can't even abstract the bit density of the screen away from the programmer (reminiscent of the old IBM/JCL decks I've had to debug, "no no no, you can't specify 8000 bytes/track on a 3330 you fool!!!") For example, I was just writing an X11 widget which is a general purpose "meter", something with marked points and hands etc. If you resize the meter there's no problem redrawing the hash marks or hands to conform nicely, but what to do about the fonts?? (eg. markings around the edge), not much except guess that some other font size *might* now be appropriate, sort of, using some threshold calculation (and hope that size is available in this server etc.) Generalized text can be even worse and the whole model (X) lends itself to such absurdities as distributing one bitmap font set on the tape (ludicrous! these are 84 dpi fonts and I'm on a 91 dpi screen, that's enough to make kerning etc just look wrong (and forget things like Hi-res monitors) and was my motivation for writing "gfto" which at least lets you regen fonts for your screen dpi, tho that only addresses part of the problem.) On the other hand, there it is (X), and it basically works quite well AS ADVERTISED and fits a model of subroutine access nicely enough (although object data management in C is less than wholesome, I'm not sure that mere Postscript can quite address that although an object oriented approach helps, at any rate, that's not *obviously* a fault of X but might be a sin of omission.) But NeWS seems to solve the imaging problem trivially (while creating others, like who the heck *wants* to program in postscript other than Don Hopkins :-) Why couldn't the whole remote interpreter thing (in re X) be more or less resolved by judicious use of the "rsh" command? Aren't window handles global? So why not something like: sprintf(buf,"rsh %s Xfrob -wid 0x%x", HOST, WINDOWID); system(buf); Sure, that's a little slow because you have to authenticate on each command but opening a socket to a remote shell or using something like rexec/rexd/rpc directly could solve that (you get the idea.) Forking has some overhead, is it important? I dunno, Unix sez no, not in general and this case would tend to weigh in its favor (if the thing was so short-lived that fork/exec is a major factor then you may as well have computed that on the client, that's another problem, *someone* has to make all these decisions.) It does mean you'd have to compile (with its disadvantage of either needing to make the decision beforehand or incurring the delay of compiling some rcp'd code, with the advantage of course that it would now be compiled/optimized, again assuming we bothered because it was too expensive to do on the client so cost is a relative thing and run-time speed is important ultimately.) Shared libraries of course help the disk space and loading time issue etc. Don't talk to me about dynamically loaded C object decks, I've had too much blood run out of my eyes porting those beasts and until someone puts that into OS's universally I say forget it except in special cases, and whoever puts it into the system should be obliged to write the routine needed for every OS that's requested, forever. It doesn't even port between minor OS releases in most cases. Similarly one could easily imagine opening a socket to a lisp which has CLX (Common Lisp X) pre-loaded and passing lisp structs much as above (I know, all together, "lisp is a memory pig", is postscript lightweight on memory? is this still a critical issue to most people? actually lisp doesn't have to be that much of a memory pig, that's an old wives tale borne mostly of non-paged 64KB/256KW machines.) My prediction? (hmm, maybe shoulda included comp.society.futures) That something else will come along in the next coupla years making both X and NeWS obsolete, if I knew what it was I'd go ahead and implement it, make a coupla billion and leave the rest of y'all in the dust :-) Don't confuse good ideas with mediocre implementations (there, good, I pissed off everyone *again*.) -Barry Shein, Boston University
matheny@Unisyn.COM (John Matheny) (07/07/88)
As an application developer, these are some of the attributes that I considered when evaluating the X Window System and NeWS: Portability. I want to minimize the amount of effort it takes to port applications from one platform to another. Therefore, I want to use a window system that exists on all of platforms in which I am interested. The X Window System seems to have an upper hand in this at the moment. However, I believe that this may change when X.11/NeWS is in UNIX V.4 and when vendors stop telling and start listening to their customers who understand the issues. Device independence. I want the window system to insulate my applications from having to know about the basic characteristics of the display device: output resolution, bit-mapped displays versus printers, keyboard mapping, pointing devices, color availability, etc. This lets me spend more time concentrating on the functionality of my application rather than its environment. The PostScript imaging model in NeWS supports this very well; the X Window System does not. Performance in a network environment. I want my application's user interface to perform well in a wide variety of configurations: same machine, machines separated by a high-speed LAN, machines separated by a phone line. Therefore, I want the flexibility of putting all or part of my application's user interface, both input- and output- related components, close to the user where it can be the most responsive. If I use NeWS I have that flexibility. With the X Window System I am stuck with everything residing on the client. I believe that dynamic server programmability, whether it is a window system server, a compute server, or a database management server, is a key to performance. Development environment. I want the window system to include tools and/or techniques that facilitate software development. I have found that all of the functions and their arguments in the X Window System and toolkits to be at least as compilicated of a "language" to learn than the equivalent in PostScript/NeWS. I was able to become proficient in PostScript/NeWS in a very short amount of time and found a number of features that make it very attractive: it has an interpreter that I can type to and get immediate feedback; it lets me do "late binding" of variables and even functions, making my software both more simple and more general; both the input model and the output model are wonderfully flexible; and the object-oriented programming features of NeWS keep my software organized, well-structured, and extensible. I haven't had any difficulty in switching between C-based application programming and NeWS-based user interface programming. In summary, NeWS meets my window system requirements much better than the X Window System. NeWS offers a programmable server for dynamic extensibility and superior performance in a network environment, features a very powerful stencil/paint graphics model that is device- and resolution-independent, and facilitates development with an interactive, object-oriented environment. All of these are features that I want when building state-of-the-art application user interfaces. -- John Matheny Internet: matheny@Unisyn.COM UUCP: uunet!unisyn!matheny Unisyn, Inc., 3300 Mitchell Lane, Boulder, CO 80301 +1 303 443 7878
carlson@aftac.tis.llnl.gov (John Carlson) (07/07/88)
In article <23656@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >I am very sensitive to the "imaging model" issue. One of the first >things anyone attempting to write a toolbox in X runs into (at least >any honest person) is the whole issue of pixel sizes and relative >metrics, particularly with fonts, big problem with X, claims of >"portability" seem to slip away when they can't even abstract the bit >density of the screen away from the programmer (reminiscent of the old >IBM/JCL decks I've had to debug, "no no no, you can't specify 8000 >bytes/track on a 3330 you fool!!!") Ideally I could scroll my display around a large root window. Call it a virtual windowing system (swap and page rectangles?). Also, I may want to zoom in on a particular window, if it is a graphics display, or if the text is too small to read. >Why couldn't the whole remote interpreter thing (in re X) be >more or less resolved by judicious use of the "rsh" command? >Aren't window handles global? So why not something like: > > sprintf(buf,"rsh %s Xfrob -wid 0x%x", HOST, WINDOWID); > system(buf); > >Sure, that's a little slow because you have to authenticate on each >command but opening a socket to a remote shell or using something like >rexec/rexd/rpc directly could solve that (you get the idea.) Using rsh in a window system is like using rcp in a file system. We should be able to share windows between servers (hosts). What I type in a window on my display/screen will appear in the same window on your display/screen without the application knowing! I would like to move a window from my display/screen to your display/screen with my window manager assuming permissions are OK. [ I think HP did something like this with X11 ] >Similarly one could easily imagine opening a socket to a lisp which >has CLX (Common Lisp X) pre-loaded and passing lisp structs much as >above (I know, all together, "lisp is a memory pig", is postscript >lightweight on memory? is this still a critical issue to most people? >actually lisp doesn't have to be that much of a memory pig, that's an >old wives tale borne mostly of non-paged 64KB/256KW machines.) I would prefer some kind of interpreter. Take your choice between X10, X11, Lisp, PostScript, NeWS, ANSI C, Smalltalk, or next year's language. Also, I should be able to mount local window hierarchies and EXISTING remote window hierarchies on my root window wherever I like. [ Some of this can be done under NeWS and X11 ] >My prediction? (hmm, maybe shoulda included comp.society.futures) > >That something else will come along in the next coupla years making >both X and NeWS obsolete, if I knew what it was I'd go ahead and >implement it, make a coupla billion and leave the rest of y'all in the >dust :-) Drop a few million my way. I won't mind. "These aren't my ideas, they are old ideas rehashed." John Carlson
warner%s3snorkel@S3DAWN.ARPA (Ken Warner) (07/07/88)
>My prediction? (hmm, maybe shoulda included comp.society.futures) >That something else will come along in the next coupla years making >both X and NeWS obsolete, if I knew what it was I'd go ahead and >implement it, make a coupla billion and leave the rest of y'all in the >dust :-) Smalltalk-90 anyone? Ken "Jus' Lookin' for Trouble" Warner
klee@daisy.UUCP (Ken Lee) (07/08/88)
There seem to be at least 2 very different sets of workstation users out
there. Each has very different needs.
Academic users tend to write small, interesting programs. For them,
NeWS is superior because it is more elegant and theoretically powerful.
Note that Sun only had to add a small number of features to graft X onto
the NeWS server for the X/NeWS merge. Adding NeWS to an X server would
have been a major overhaul. See the paper in the last USENIX
proceedings for details.
Industrial users, like myself, prefer X. It is much more complete
(e.g., lots of toolkits and window managers), more robust, and, most
importantly, is (or soon will be) available for almost every engineering
workstation. All the manufacturers are supporting X to some degree.
We do lose some functionality, but X is more than powerful enough for
most current applications programs.
The competition between the 2 systems is, of course, good. Future
window systems will include the best features from both (if the lawyers
don't interfere). The X/NeWS merge is still too kludgey for most
people, but it may mature into a very nice system. Stay tuned.
Ken
--
uucp: {atari, nsc, pyramid, imagen, uunet}!daisy!klee
arpanet: atari!daisy!klee@ames.arc.nasa.gov
STOP CONTRA AID - BOYCOTT COCAINElantz@orc.olivetti.COM (07/08/88)
>> We should be able to share windows between servers (hosts). >> What I type in a window on my display/screen will appear in the >> same window on your display/screen without the application knowing! I >> would like to move a window from my display/screen to your display/screen >> with my window manager assuming permissions are OK. >> [ I think HP did something like this >> with X11 ] >> >> ... >> >> Also, I should be able to mount local window hierarchies and EXISTING >> remote window hierarchies on my root window wherever I like. >> [ Some of this can be done under NeWS and X11 ] The group at HP is led by Phil Gust. Several groups other than HP have also implemented variations on these features by now -- including my own, a group led by Phil Janssen at MCC, and a group led by Sid Ahuja at Bell Labs. These groups (and others) are even trying to work together somewhat, hopefully to the greater glory of everyone. Further information can probably be obtained by sending to "sharedx@expo.lcs.mit.edu"; that list could use some traffic! Keith A. Lantz Phone: (415) 496-6235 Olivetti Research Center Internet: lantz@orc.olivetti.com, or 2882 Sand Hill Road, Suite 210 lantz%orc.uucp@unix.sri.com Menlo Park, CA 94025 UUCP: {acornrc,oliveb,sri-unix}!orc!lantz
janssen@titan.SW.MCC.COM (Bill Janssen) (07/12/88)
In article <8807071850.AA11774@tuscany.orc.olivetti.com>, lantz@orc.olivetti.COM writes: > group led by Phil Janssen at MCC That's Bill... We have a nice pseudo-server running. One of the things it can be used for aside from the conferencing is to provide multiple X screens on a single display device. Quite handy. Bill -- Bill Janssen, MCC Software Technology Program ARPA: janssen@sw.mcc.com UUCP: {seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!janssen