Path: utzoo!attcan!uunet!mcsun!ukc!slxsys!tsa!domo From: domo@tsa.co.uk (Dominic Dunlop) Newsgroups: comp.windows.x Subject: Wanted: Pointers to materials describing extensions to X (long) Message-ID: <1990Jun8.083647.10924@tsa.co.uk> Date: 8 Jun 90 08:36:47 GMT Sender: domo@tsa.co.uk (Dominic Dunlop) Reply-To: domo@tsa.co.uk (Dominic Dunlop) Organization: The Standard Answer Ltd. Lines: 252 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 Dunlop