Xref: utzoo comp.windows.news:583 comp.windows.x:4140 Path: utzoo!attcan!uunet!yale!husc6!bu-cs!bzs From: bzs@bu-cs.BU.EDU (Barry Shein) Newsgroups: comp.windows.news,comp.windows.x Subject: Re: is news loosing the battle? Message-ID: <23656@bu-cs.BU.EDU> Date: 6 Jul 88 23:39:03 GMT References:<10250002@hpfclp.SDE.HP.COM> <17063@tut.cis.ohio-state.edu> Organization: Boston U. Comp. Sci. Lines: 101 In-reply-to: elwell@ichthyosaur.cis.ohio-state.edu's message of 6 Jul 88 18:44:31 GMT 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