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