domo@tsa.co.uk (Dominic Dunlop) (06/08/90)
I'm writing up a (private) report on the fit between X Window and other
existing or proposed aspects of ``information technology'' (computing).
I'd be grateful -- and would, of course, summarize to the net if enough
material arrives and enough people express an interest -- if you could
give me pointers to literature, or even to people, which could provide
information on extensions or modifications to X (let's say to X11R3) in
the following areas:
1. Device independence
2. Division of work between client and server
3. Graphics model
4. Interactive video
5. Internationalization
6. Network independence
7. Programming model
8. Security
9. Sound
If you want the full, 225-line story, hit that space bar now! And thanks.
Wanted: Pointers to materials describing extensions to X
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!
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) and
for its failure to incorporate a printing model as well as a display
model. The graphical user interface in most widespread use, that for
the Apple Macintosh (dispute this if you will, Microsoft), is of a
similar vintage to X, and is also tied to display resolution -- a
factor which complicates its printing model.
Following leads from Adobe, Sun and NeXT, Apple has teamed up with
Microsoft in a move which will replace the bitmapped fonts of the
current Macintosh System, and of Microsoft's Windows and Presentation
Manager with outline fonts, and which will add a unified printing
model.
Are there any similar developments which are applicable to X? (Clue: I
should be interested to hear of developments which add PostScript to
the X Window display model.)
2. Division of work between client and server
The functionality of X is divided between client programs and servers.
At the time of design, typical servers were assumed to be ``3M''
systems: a million instructions per second, a megapixel, and a megabyte
(or two) of RAM. [Berkeley UNIX on 1000 Workstations: Athena Changes
to BSD, G Winfield Treese, USENIX Conference Proceedings, Winter,
1988]. To this, one can add a fourth ``M'': a megabit or so of
effective network throughput. Design decisions, such as the lack of
provision for costly operations such as the rotation and scaling of
bitmaps, appear to be a result of the desire to produce a system which
would perform acceptably on such hosts. There also appears to be an
assumption that the processing power ``behind the glass'' -- that is,
in the server -- is limited, and that the network capacity between
client and server is comparatively high. Thus, the client program can
perform any expensive operations that it may need, sending the results
quickly over the network to the server.
Today, these decisions can be constricting: computing power available
to servers has increased greatly, while (pending the widespread
installation of FDDI) network capacity has remained static, or, if one
takes into account the appearance of high-speed dial-up modems and the
integrated service digital network (ISDN), actually fallen.
3. Graphics model
X presents a comparatively simple graphics model; it has little in
common with engineering graphics systems such as GKS or PHIGS, and
pales in comparison to PostScript. However, it is eminently possible
to implement these and other systems on top of X; Adobe and Digital
have done it with PostScript.
What is the status of these implementations, and those of other
graphics systems?
Under Device Independence above, it was mentioned that X uses bitmapped
fonts. Those shipped with the X distribution do not, for copyright
reasons, correspond exactly to popular, commercially-available fonts.
(Actually, copyright on fonts in the U.S. is a weird issue, which I'll
skip over.) On the other hand, hundreds (or thousands, depending on
how you count them) of commercial fonts are available in (encrypted)
outline form for PostScript, or in plain form (but without Adobe's
proprietary shape-improving hints) for PostScript clones.
Is there a way in which, say, a future X-based desk-top publishing
application could gain access to a wide range of ``name-brand'' fonts
without requiring the use of PostScript? I am not aware of any plans
by font suppliers such as Adobe, Bitstream and Monotype to provide
support for X. But perhaps I didn't ask the right people... Or might
Apple/Microsoft's ``Royal'' outline fonts be dropped into X? Seems
unlikely.
4. Interactive video
A number of companies have demonstrated special-purpose display
hardware which allows moving video to be displayed in a window on a
screen managed by an X server. These developments are made more
interesting by the (supposed) emergence later this year of an ISO
standard which will resolve the long-running battle between DVI and
CD-I as a method of recording (considerably compressed) video on
standard compact discs, and which could result in widespread use of the
technology. (For lobby watchers, CD-I, from Philips, cheered on by
Sony, Motorola and other, is the favourite, with Intel, IBM and, I
think, RCA on the side of DVI.)
Is there any visible convergence on a common set of operations and
programmatic interface for systems capable of integrating video
elements with computer displays?
5. Internationalization
X does better than many software environments in that many of its
29-bit KEYSYMS correspond to international standards 8859-1 through -4,
which define a series of related 8-bit character sets capable of
handling languages using Roman alphabets (Western European languages
besides Greek). X also supports Arabic, Cyrillic, Greek and Hebrew
characters, in a manner said to be compatible with the corresponding
ISO standards, 8859-6, 8859-5, 8859-7 and 8859-8 (although I have not
checked this in detail).
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. (Not that the vast majority of other systems do any
better.)
X11R3 also supports Kana and a variety of typesetting, mathematical,
APL and commercial symbols, together with ``special'' keys, for which
there are no international standards as yet. Extensions to X support
further Japanese character sets, and possibly other Asian ``alphabets''
(substitute term of your own choice).
ISO has for some years been trying to solve the problem of character
sets once and for all with the 32-bit draft proposal 10646, which will
do all of the above, plus Inuit, and anything else you can think of.
10646 follows the 8859 (and the earlier 646) standards when
appropriate, and so parts company with X beyond 8859-8 or so. I'm not
aware of any explicitly tie-up between X and DP 10646.
Is this summary correct, and what work is in progress (if any) to
change things? Also, are there any other internationalization aspects
to X that I should be thinking about besides character sets and string
drawing?
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. Support was also
provided for the proprietary DECnet, for similar reasons. ISO
protocols, in their infancy when the development of X got under way,
were not, and are not (yet) supported. This has proved something of an
embarrassment as moves towards international standardization of X gain
momentum. ISO's attitude to communications is that, if you can't do it
with OSI, you can't do it. (This despite many indications that the
TCP/IP and OSI communities are at last coming to realise that
coexistence is more productive than confrontation.) As a consequence,
the ANSI X3H3.6 working group has set itself the task of removing
TCP/IP dependencies and assumptions from the X protocol (or data stream
encoding, as standards people like to style it), as a prelude to
introducing the work to ISO.
Is this a fair summary? And is there a prospect of support for further
protocol families, such as IBM's SNA?
Another network-related aspect of X is that of its bandwidth
requirement. (See also Division of Work above.) Competitive
technologies such as Sun's NeWS, by expecting the server to do more
work, and by compressing already short PostScript messages, can reduce
network traffic to the extent that operation over an 9,600 bps link is
said to be ``surprisingly good'', if not wonderful. [At Home with
X11/NeWS Windows, Mark Opperman, USENIX Conference Proceedings, Summer,
1989]. 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. (Indeed, the paper mentions ISDN capability as a future
direction.)
It is not clear that X can match such achievements. Is it even
trying? Is there much U.S. interest in making it do so, given the
comparative ease and low cost (relative to most of the rest of the
world) with which 1.5 Mbps T1 circuits can be obtained? (What's the
CCITT near equivalent to T1? I forget.)
7. Programming model
Officially, the programming interface to X is published in terms of
Kernighan & Ritchie-ish C. This has not prevented X from using an
object-based programming model, which requires somewhat more discipline
to manage than most C programmers are used to applying. There has been
some bitching about this, and about Xlib, intrinsic and widget set
function calls which require gadzillions of parameters, and which make
it difficult to write the Spartan, yet hopefully readable, programs
considered to be the height of C programming style. (It might be
argued that this problem is a consequence of writing event-driven
applications in a batch-loving third-generation language, but that's
another story.)
Some X toolkits written in C++ have appeared. As a C hacker long gone
rusty, I have to admit to a yawning lack of knowledge of these, and
would love to see a taxonomy. They ought to go a long way to answering
the criticism of the C language interface to X. Do they in fact? And
is there an ``official'' C++ binding to Xlib?
Also, what is the status of X with respect to the at-last-ratified ANSI
standard C? Are there de facto standards (or, indeed any existing
practice) for interfacing X to other languages such as Ada and
FORTRAN?
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).
With X set fair to become a U.S. and international standard, and with
government and military organizations grabbing at anything bearing the
label ``standard'', but also very interested in having secure systems,
several organizations are working on making X secure. Who are they?
What is their approach? How successful have they been? How close are
the fruits of their labours to market?
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. Or maybe
it was to some server implementation meticulously noting that all it
could do was ring the bell. Further clues, anyone?
That's it. Please copy reply by mail. If you post, copy by mail, as I
won't be reading news for a week, and would hate to miss anything because
it got expired. Thanks.
--
Dominic Dunlopdomo@tsa.co.uk (Dominic Dunlop) (06/08/90)
In article <1990Jun8.083647.10924@tsa.co.uk> domo@tsa.co.uk (Dominic Dunlop) (that's me) writes: >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. Well, I got this wrong: the direction member in XFontStruct accommodates left-to-right or right-to-left, but not vertical text. -- Dominic Dunlop
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (06/10/90)
> 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
ekberg@ti-csl.csc.ti.COM (06/11/90)
From: mcsun!ukc!slxsys!tsa!domo@uunet.uu.net (Dominic Dunlop) > Some X toolkits written in C++ have appeared. As a C hacker long gone > rusty, I have to admit to a yawning lack of knowledge of these, and > would love to see a taxonomy. They ought to go a long way to answering > the criticism of the C language interface to X. Do they in fact? And > is there an ``official'' C++ binding to Xlib? Yes, X toolkits written in C++ do exist. The two I have most knowledge of are the InterViews toolkit developed at Stanford and the C++ interface to Motif developed at the University of Lowell. InterViews defines an interface to a window system, which happens to be X, using much of the C++ language to obtain its many features. The user doesn't know that the underlying window system is X. It has been stated that one could unplug the InterViews code which talks to Xlib and plug in code which talks to another window system. The C++ interface to Motif developed at ULowell is more than just a simple C++ interface to Motif. It actually defines C++ classes and methods that allow the developer to interface to the Motif widgets using C++ instead of Xt. > Are there de facto standards (or, indeed any existing practice) for > interfacing X to other languages such as Ada and FORTRAN? ULowell has sent me an information sheet which mentions their Ada and FORTRAN interfaces to Motif. I occasionally see messages on mail.x-ada about an Xlib interface in Ada and have seen passing reference to wanting the same thing for FORTRAN. Don't leave out my favorite language: Lisp. There has been for some time a Common Lisp interface to X called CLX. This is the Lisp equivalent to Xlib. There is also an Xt and toolkit equivalent written in Common Lisp. If you want more information on these let me know. -- tom (aisle C-4Q), ekberg@csc.ti.com
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (06/11/90)
1. Device independence
Many vendors are working on support for outline fonts in X; Sun already
has shipped support as part of OpenWindows. Work is on-going within the
Consortium in this area. Adobe is working with various vendors to put
Display PostScript into the X environment. OpenWindows is a different
approach to PostScript integration.
2. Division of work between client and server
I would dispute several things here, but I don't have time.
3. Graphics model
I believe you are mistaken about "copyright" issues. We have had
discussions with a number of font suppliers about supporting their
fonts in the X environment. Work is on-going within the X Consortium.
4. Interactive video
Todd Brunhoff at Tektronix has been leading efforts to standardize an
X extension for video. The work is reasonably far along (alpha test
of an implementation).
5. Internationalization
There is considerable activity within the X Consortium in this area.
We are working to get documents out for public review.
6. Network independence
There are no "dependencies" on TCP/IP in the X protocol. X3H3.6 is indeed
working to produce a standard mapping of X onto OSI. Talk to X terminal
vendors (e.g. NCD, GraphOn) about running over 9600 baud lines; there are
people who do it daily.
7. Programming model
There is no "official" C++ interface to Xlib, save the normal C interface.
Lots of vendors are working on C++ interfaces to X, at various levels.
There are one (or two?) Ada bindings kicking about. Several vendors have
Fortran interfaces. None of them are "standard".
8. Security
Several vendors are working on B1/CMW prototypes/products. At least one vendor
is working on more "commerical" security aspects. You'd have to ask the
vendors about schedules.