Path: utzoo!attcan!uunet!husc6!bloom-beacon!ATHENA.MIT.EDU!wdc From: wdc@ATHENA.MIT.EDU (Bill Cattey) Newsgroups: comp.windows.x Subject: R3 Selection Mechanism -- The emperor has no clothes! Message-ID: Date: 17 May 89 06:55:46 GMT Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 219 I am writing this note in the hope that the X Consortium will consider returning to a simpler mechanism for exchange of data between X clients than the selection mechanism. I believe that the Consortium's present direction of adding complexity to solve problems is begining to result in a total system that is too big, and too complicated for the amount of utility each increment in complexity buys. The rest of this paper is a justification for the following simple proposal: Eliminate the entire selection protocol and use the cut buffer protocol exclusively. Make the cut-buffer implementation smarter to handle large data transfers. The selection mechanism provides the following utility: 1. Exchange of data among X clients. 2. Signals for clients to know when another application has taken the selection. 3. Signals for clients to know when a new selection has been established by another client. 4. Ability to convert among a diverse variety of formats for efficient data transfer between clients. 5. Ability to name and recall a variety of co-existing selections such as PRIMARY, and SECONDARY. 6. Ability to manage large data transfers through handshaking. Although these are not all the utilites, they are the most prominent ones named in the ICCCM. This functionality is purchased at the following costs: 1. Any client wishing to acquire the contents of a selection must send a timestamped request to the server, and must have support for the Selection Notify event. 2. Any client wishing to create a selection must accept the responsibilites of a selection owner: It must have support for a Selection Request event. This event support must determine if it can convert the data to a requested target format, and must support data conversion for each target format. It must support the Selection Clear event to give up the selection. Most importantly it must know how to contact the window server to ask for ownership of the selection. 3. Although a client need not support format conversions, support for each conversion is the responsibility of the author of the client program. 4. A user running a client which will receive the contents of the selection is required to wait for the operating system to swap his or her program out, and the selection owner in, just to get the data. 5. A user's client program that is establishing a selection gets swapped out if another client owns the selection, then back in to establish the selection. How do these costs and benefits balance out in real applications? 1. Wasteful of the user's time. The most common use of selections, to cut and paste between windows is quite expensive. As mentioned in #5 above, the user's client must be swapped out and then back in. But the common use of grabbing data into a program and then using that program for a while, means that the application just swapped in and then out must then get swapped back out. This problem will go away when all X users run on machines where context switches are not expensive, but such will not be the case for quite some time. An algorithm that reduces this time will be noticeable to users for the forseeable future. 2. The Data Conversion is not useful. My experience with exchanging many data formats among X clients is limited. I have made extensive use of the Andrew multi-media editor, but all the selections I paste between Andrew applications are converted to a 7 bit ASCII data stream format. The programs I have used or written which need efficient data exchange generally adopt private protocols. 3. The Selection Protocol is too hard to program. My experience with communication protocols is a little richer. I've reviewed, designed and written programs that do a lot of data exchange. The same brain that reviewed server loading issues for the Athena Zephyr notification system, and that designed the file exchange protocol for exchange of papers between MIT professors and students with the turnin/grade suite, and that wrote a multi-font text editor without much strain seems to balk at the complexity of the selection interface "tea ceremony". Maybe it's my brain, but I've got three products in the world that say your product is too complicated for me to deal with. When I talk to others about writing applications that use the selection mechanism, they too find it hard to deal with. 4. The user interface is now non-intuitive. The selection mechanism has been implemented in xterm so that when xterm B establishes a selection xterm A's selection is unhighlit. In the first 5 minutes of use, this is cute, but soon after it becomes hateful. The 'always visible' selection can scroll off the screen at any time, and the user is left with an active selection that has to be discovered by pasting. What's worse, is that most applications don't yet use selections, so the user is now forced to deal with two selections that often can't be seen where once he only had to deal with one invisible thing. A few hours using R3 xterms has proven to me that implementing signaling to clients as the selection shifts between them is a LOSE! I will be VERY HAPPY if xterm goes back to unhighlighting the selection when my mouse leaves the window. Every application won't support the sophisticated "one selection only" rule, and those that do don't buy me much at all. 5. Bringing applications into conformance is hard. The toolkit intrinsics contain support for the selection protocol, but not every X application is or should be forced to be a toolkit application. Having support in the intrinsics does no programmer any good until they feel comfortable dealing with the protocol which was already shown to be too complicated in #3 above. The additional layers to the toolkit to make it easy for the less sophisticated programmers do not yet exist, and when they do, they will come at the expense of larger programs. It should not cost what it does now to allow programmers to interface their clients to other clients. 6. The simpler, cut buffer protocol makes it worse! There is a simpler protocol, cut buffers. But the way selections are used now, any application writer who uses cut buffers forces the user to deal with the non-intuitive user interface described in #5 above. Since selections are tested first by applications in full conformance, there is always the potential that the user of the suite of applications will be dealing with two invisible chunks of data and pasting the wrong one in at the wrong time. If we allow the selection mechanism to change, we will be exercising an opportunity to buy into the following good things: 1. Lower overhead: The client programs will not be required to context switch. 2. Simpler user interface: There should be only one selection that the user should have to worry about. If there are to be several selections, an application should be written to browse through them and make a particular VISIBLE one "THE" selection for exchange. 3. Simpler programmer interface: Every X client should be able to exchange data. Programmers who are less sophisticated should not be forced to penalize their users at the basic cut and paste level. An application that just draws a few simple graphics should remain simple, but still be a full member of the community when it comes to user interface. 4. Appropriate data conversion protocols: Sophisticated clients requiring fast efficient cooperation for the exchange of data should be using a communicaition channel, not a window system to exchange their data. The Andrew system is proof that diverse media types can be cut and pasted between applications by all agreeing to speak 7 bit ascii. The atk datastream protocol has one sophisticated requirement: each parser must know that when it sees '\begindata foo' it has to get out of the way and let a foo parser go from there. These parsers are supported in a library that is available to clients. Every client is not required to translate every format in order to support sophisticated multi-media exchange. The only point where the cut buffer protocol clearly loses is in the area of large data transfers. It requires the server to hold the contents of the cut buffer (or buffers). The implementation assumes the server will allocate memory and store the data in the server. Yet there is no way to find out if we are running out of memory. Memory is a dynamic thing, and it is virtually impossible to tell a client how much there is. Originally I was going to assert that applications exchanging large blocks of data should use a communication protocol not a window system protocol. But I have often wanted to paste a 300 line xterm output into an emacs buffer, and I should be allowed to do things like that. My suggestion is this: 1. The un-sophisticated programs will be forced to be limited in the amount of data they can write. All applications will have to handle an error from XStoreBytes (for example) which means that the server didn't have enough memory. Un sophisticate programs tell the user 'sorry'. 2. Sophisticated programs implement a simplified variation on the selection mechanism that allows them to respond to requests from the server for the data it 'has in the cut buffer'. Client B calling XFetchBytes (for example) would wake up client A which would pour in the data in chunks. 3. The fetch operation should return a signal if the fetch didn't return all the data available in the cut. Handling this is no more complicated than what programmers already put up with when they break up a read system call. 4. This adds one non-intuitive aspect to the user interface: programs 'owning' large 'cuts' must be running to supply the data. Programs 'submitting' small 'cuts' need not. The user might get confused. Of course this situation exists in the present scheme, but is much worse for the user. If my present, intentional, mis-understanding of the existing cut buffer and selection mechanism are on target. I have given you a proposal which results in a more useful system, which is easier on your programmers and your users. Face it guys! We must begin finding creative ways to reduce, not increase the X complexity. From the 'desk' of _ /| Bill (the) CATTey... \'o.O' ~(___)~ THSHVPPPOOO! U ACH!