Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!SHAMASH.MCRCIM.MCGILL.EDU!mouse
From: mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  Wanted: Pointers to materials describing extensions to X
Message-ID: <9006100359.AA17166@shamash.McRCIM.McGill.EDU>
Date: 10 Jun 90 03:59:02 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 112

> I believe the following to be correct, but don't take it as gospel,
> as it comes almost straight off the top of my head, and before I've
> done adequate research.  If you know anything to be incorrect,
> incomplete or inaccurate, I'd appreciate correction.  Even flames!

Even flames!  What commitment! :-)

All the following text is solely my own opinion, and as always, I may
very well be mistaken.  So caveat emptor.

> 1.  Device independence

> X has been criticized for its dependence on display device resolution
> (for example, in its use of bitmapped, rather than outline fonts)

I actually defend X for its choice here.  As long as individual pixels
can be seen (which includes not only current CRTs but even - though
just barely - a 300dpi laser printer), a pixel-based interface *must*
be available to produce high-quality output.  I've used PostScript
printers and have seen the contortions one has to go through to get
consistent pixelization out of them, and I *don't* like it.  When we
get 1000dpi screens, the time of bitmapped fonts may well have passed.

> and for its failure to incorporate a printing model as well as a
> display model.

See my comments below under "Sound".

> 5.  Internationalization

> [...] It seems to me that Xlib is biased in favour of left-to-right
> languages, in that this is the direction that strings get drawn -- if
> you want right-to-left, or vertical, you have to make your own
> arrangements.

No; right-to-left is no more difficult than left-to-right.  (Though
most software is not written to handle it, and not many widely
available fonts work this way, X is not inherently left-to-right.)  You
*are* correct about non-horizontal text.

> 6.  Network independence

> The X protocols, used to communicate between clients and servers,
> were built on top of the TCP/IP protocol suite because it was
> available, because it worked, and because it was widely used.

As I understand the X protocol, it does not depend on TCP, DECnet, or
any other specific wire protocol; it can be run over any reliable
bidirectional sequenced byte stream, regardless of how that stream is
implemented.  (Even a bare serial line would work, though personally I
wouldn't recommend it because the protocol is not robust in the face of
the sorts of errors typically found on such lines.)

> ISO protocols [...] are not (yet) supported.

All this means is that nobody's got an implementation.  While I don't
know the ISO suite, I find it hard to believe it can't support a
reliable bidirectional sequenced byte stream, which in turn means that
X will run perfectly well over it.

> ISO's attitude to communications is that, if you can't do it with
> OSI, you can't do it.

And IBM thinks that if you can't do it with IBM hardware and software,
you can't do it.  In both cases, well, that's their problem, right?

> [...] This would point to reasonable performance over the 64 kbps
> ISDN links which threaten to pop out of walls around the world over
> the next decade.

I've used X over 56 kilobit links, and its performance is most
certainly reasonable.  I've had worse performance without leaving the
local Ethernet.  (I can't see that an extra 8 kbps could hurt any!)

> 8.  Security

> Security was not a design goal of the X Window System.  As a result,
> it is possible to do such things as have one client read the --
> possibly sensitive -- contents of windows belonging to other clients,
> provided that the first client can determine the name of the server
> (as it usually can).

And that the reading client has been authorized to connect, by whatever
means is currently in use.  (The simplest, and doubtless most widely
used, method is based simply on the machine from which the connection
is coming.)

> 9.  Sound

> Last, and probably least, I once saw a reference to some
> implementation of being able to make noises besides the ringing of
> the bell.

Here I address as well your comment under question 1 about X not
providing a printing model.

X is not an everything-server protocol.  I see no reason why X should
be expected to provide printing services, sound-related services, or
for that matter postage-stamp purchase services.  (A strict application
of this point of view says that XBell was a mistake.  While I don't
actively support this argument, I'm not certain it's entirely wrong.)

> That's it.  Please copy reply by mail.

To whom?  You don't give any address for yourself.  (I've made a guess
based on the headers I found on this message, but I don't trust the
various mail systems involved to get it to you, not by a long shot.)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu