Re: State of the X clipboard, and perhaps a solution

[Mike Hearn <mike navi cx>]

On Thu, 22 Apr 2004 17:29:12 -0500, Jerry Haltom wrote:
> The problem here is what data type do we send to the escrow daemon? The
> primary one? All of them? The only proper answer, in order to satisfy
> requirement 1 is to send all the data. This however is not reasonable.
> We could be talking about a multi-gigabyte movie file, or audio data. Or
> maybe audio data available in 4 different audio formats. This is
> immediately obvious as not being practical to offload to a escrow.

I really don't think it's practical to send gigabytes of data via the X
server in *any* situation, escrow daemon or waiting-to-quit processes. I
suspect that even on a local link, that would hose the X server or at
least take so long that the user would get bored and quit :)

For the common case of the two processes on either end of the copy/paste
(or drag/drop) it'd probably be better to use shared memory to transfer
the data between two apps. AFAIK you can map a block of memory into
another process, the original process can quit and the memory lives on.

In other words, it might be smarter to extend X so that if you do a
copy/paste between two processes on the same machine, the data is simply
remapped into the other process rather than transferred via the X protocol.

Network transparency doesn't have to be lost. In the (rare) case where you
copy and paste between two apps running on different machines, the X
server is an ideal conduit for moving the data. But woe betide anybody who
sends 200mb of audio via a network link like that :)

That would make using escrow daemons a lot more realistic, though you
still have a problem if your audio app pastes a 200mb sample available
using 10 different codecs :)

> And here we get to the answer, maybe. The only way to satisfy the above
> requirements (that I can think of) is to keep the data and code
> available in memory during the duration that it owns the clipboard
> contents. This means long living processes of some sort. 

It's a nice idea, and may well be doable, but I'm concerned this could
lead to a lot of subtle bugs. You say that "most of the app would
be unloaded anyway", but I don't think that's true.  In order to perform
format conversion for most apps I can think of they'd need to keep the
majority of the app in memory, unless they did it ahead of time (in which
case you might as well just use an escrow daemon and shared memory).

In particular, if a toolkit was adapted to mostly but not actually quit
when holding the selection, I can see all kinds of evil crashes caused by
apps using resources that were already freed. Suspending an apps shutdown
then running arbitrary codepaths is not a change to be taken lightly.

As already mentioned this also leads to wierd semantics with single
instance apps and stuff ... definitely scary :)

> Anyhow, discuss. I want to hear pros/cons, etc. This proposal doesn't
> require any new specifications of interprocess communication at all,
> simply a modification to the life-cycle of a program... which is handled
> by libraries such as GTK and QT.

And modification of most of the apps. But I think that's probably
inevitable anyway.

It'd be nice to get some speed tests to find out how much data you can
throw through the X server using xincr per sec, but really for the things
you're talking about simply shuffling the memory between processes using
the standard posix calls is probably OK.

In the case where an app supports so many formats it'd generate unfeasable
amounts of data, the user could just choose which format to copy ahead of
time. Keeping the app persisted around in this case could have toolkit
support but I'm not sure it's wise to make it the default....