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

[Jerry Haltom <jhaltom feedbackplusinc com>]

> 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 :)

I agree with this 100%. A few ideas I have considered:

X could have a bulk data transfer protocol (if it doesn't already). This
would allow any two programs on the X server to bulk transfer data to
each other. This would be implemented as a pipe for local connections,
and just a proxy for remote connections. A pipe could connect the two
local processes directly.

For two remote apps... I don't know. Needs more thought. :0

> 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....

I don't think putting the burden on the user to decide stuff about
formats is reasonable. My users don't even know what a format is. To
them a JPEG is a Picture, just like a GIF or PNG. :0