wdc@ATHENA.MIT.EDU (Bill Cattey) (05/17/89)
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!dshr@SUN.COM (David Rosenthal) (05/17/89)
Bill Cattey suggests: > Eliminate the entire selection protocol and use the cut buffer protocol > exclusively. Make the cut-buffer implementation smarter to handle large > data transfers. > As the editor of the ICCCM, I have a number of comments, of which only the first is important. - Drafts of the ICCCM (including the selection mechanism) have been available since R2. I presented a draft for public review at the MIT X workshop in January, and carefully pointed out how comments were to be made. The comment period ended March 31. Suggestions such as Bill's should have been made before this deadline. At some point, we have to accept a set of conventions and use them. That point has now passed. You have all had plenty of warning that this was about to happen; you have all had ample opportunity to raise issues that worried you. The ICCCM is no longer open for comment; no further changes will be considered unless and until the Consortium schedules a revision of the document. Given the costs associated with changing these conventions, I would guess that this would be unlikely in the next few years. - Given the presence of limited-memory X servers, the cut-buffer mechanism is vulnerable (all data has to be stored in the server). The ICCCM selection mechanism adapts to the amount of memory available in the server (using the max-request-size in the connection handshake). This alone is enough to deprecate use of cut-buffers and encourage programs to use the selection mechanism. - The message shows a number of misunderstandings of the selection mechanism. for example: > 3. Signals for clients to know when a new selection has been established > by another client. > No such capability (except if the client lost a selection in the process). > 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. > Establishing conventions between applications takes time, but there are many clients right now using targets such as FILE_NAME and LINE_NUMBER to coordinate (for example) between debuggers and editors. This is a simple example to show the range of capabilities the selection mechanism offers that cannot be provided by cut-buffers. Note further that the ONLY reason the cut-buffers are in the X spec is precisely to support Andrew, and that saying that Andrew works well with the cut-buffers is therefore hardly news. > When I talk to others about writing applications that use the selection > mechanism, they too find it hard to deal with. > Toolkit support for the selection mechanism is underway. It could not be finalised until the lower-level protocols were stable. > 4. The user interface is now non-intuitive. > The selection mechanism does nothing to mandate a user interface. Your criticism are directed to xterm, which had necessarily to deal with an early version of the selection mechanism. > 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. There is no such requirement. The cut-buffer and selection mechanisms are completely independent. David.
geek@mit-amt (Chris Schmandt) (05/18/89)
In article <gYQFRmQGG047NGTW0K@athena.mit.edu> wdc@ATHENA.MIT.EDU (Bill Cattey) writes: >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. >... >Eliminate the entire selection protocol and use the cut buffer protocol >exclusively. Make the cut-buffer implementation smarter to handle large >data transfers. Rarely do I have anything to say to this list, but... The selection mechanism in X is provides an extremely powerful method of inter-client communication, as well as some very useful (for extensions, anyway) means of negotiated how "typed data" may be exchanged. There is every reason to keep it! I will not go into much detail, but... 1) Selections may exist for any atom, including new ones you get the server to create for you. I've written clients who do things like dial phones through a single "dialer" process by exchanging ownership of the "PhoneNumber" selection. This provides much needed extensibility. 2) The actual series of context switches to obtain the contents of the selection provides a nice way of synchronizing activity between clients, which (details omitted) is also quite powerful 3) A cut buffer merely exists and is there for the grabbing. Selections allow negotiation about how the selection contents may be converted. For example, we're supporting "sound files" and "phone numbers" as data types, in addition to such commonality as XA_STRING. Suddenly we get some nice inter-client operability in a multi-media environment. 4) If you find selections hard to program, you will find X impossible so you may as well quit. I am used to it taking 3 hours (including reading the source and doing a test program) to figure out how to do anything new in Xt. Selections took about 1/2 hour. Can't get much easier. 5) If multiple "selections" appear highlighted, that's bad client behavior, not bad mechanism. In fact the biggest problem remains Emacs, which uses cut_buffers instead of selections. 6) Finally: I started using X-windows because I hope it is a window system of the '90s. To build exciting clients and user-interfaces your base must be strong and flexible. Sure, X is a bit of a moving target as things like the ICCCM get resolved, and it will be some time before things are consistent as we'd like in this regards. Simplicity should be manifest in the user-interface, NOT in the underlying architecture supporting it. In short (though I know it would not happen!), if the selection mechanism were dropped as the original poster suggested, it would be time for me to find a new window system for my work... chris
bet@dukeac.UUCP (Bennett Todd) (05/18/89)
In article <3786@mit-amt> geek@media-lab.media.mit.edu (Chris Schmandt) writes: > ... > Simplicity should be manifest in the user-interface, > NOT in the underlying architecture supporting it. Is this sentiment common among X supporters? Truly, comp.windows.x is your group, and I don't want to go picking fights; I've had to delete my first two tries at posting this article. But does *anybody* see anything wrong with the above statement, and the design philosophy it implies? Or am I just really strange in my head (probable:-). -Bennett bet@orion.mc.duke.edu
dsill@RELAY.NSWC.NAVY.MIL (05/19/89)
>From: ecsvax!dukeac!bet@mcnc.org (Bennett Todd) >In article <3786@mit-amt> geek@media-lab.media.mit.edu (Chris Schmandt) writes: >> ... >> Simplicity should be manifest in the user-interface, >> NOT in the underlying architecture supporting it. > >Is this sentiment common among X supporters? > >... But does >*anybody* see anything wrong with the above statement, and the design >philosophy it implies? Or am I just really strange in my head (probable:-). To say that simplicity belongs only in the user interface is both right and wrong. It's right because the user interface is where simplicity is needed and is often the only place where it's possible to achieve. It's wrong because it implies that developers aren't users. The programmatic interface to a window system or operating system is as much a "user interface" as the interactive keyboard/display/mouse interface that we usually consider *the* user interface. Much of UNIX's success is due to its programmatic interface (and, some would say, in spite of its interactive interface). I'll let you draw your own conclusions about how this applies to X. -Dave (dsill@relay.nswc.navy.mil)
asente@decwrl.dec.com (Paul Asente) (05/19/89)
>From: ecsvax!dukeac!bet@mcnc.org (Bennett Todd) >In article <3786@mit-amt> geek@media-lab.media.mit.edu (Chris Schmandt) writes: >> ... >> Simplicity should be manifest in the user-interface, >> NOT in the underlying architecture supporting it. > >Is this sentiment common among X supporters? > >... But does >*anybody* see anything wrong with the above statement, and the design >philosophy it implies? Or am I just really strange in my head (probable:-). Chris was perhaps overstating the case; to be completely correct I would have said "Simplicity should be manifest in the user-interface, and if complexity is necessary underlying architecture to support it, it's unfortunate but life isn't always easy." There are many examples of this in the X architecture. The vast number of gotchas that apply to request redirection are necessary in order to allow consistent window manager operation across all windows. Someone here at DEC started rooting around in the intrinsics on the theory that all the complexity wasn't really necessary but kept coming to the conclusion that yes, it really *was* necessary to support consistent user interfaces. The selection mechanism is just another example of this. One thing selection provides that hasn't been discussed yet is synchronization between clients. If you make a selection in one window, paste (or otherwise use it) in another, then make another selection, what happens if the client in the second window is slow and doesn't get around to fetching the selection until after you've made the other one? Believe me, this *can* happen. All the timestamp business in the selection mechanism is to allow this to work right. Yes, complexity is to be avoided when there is a simple alternative, but sometimes there is no alternative. Of course sometimes we may just all be too dense to see what the alternative is, so we should be open to new suggestions about how to do things, but we have to make sure the simple alternative really solves all the problems. -paul asente asente@decwrl.dec.com decwrl!asente