Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!SUN.COM!dshr
From: dshr@SUN.COM (David Rosenthal)
Newsgroups: comp.windows.x
Subject: Re: R3 Selection Mechanism -- The emperor has no clothes!
Message-ID: <8905171610.AA17225@devnull.sun.com>
Date: 17 May 89 15:44:37 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 75

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.