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

[Mike Hearn <mike navi cx>]

On Fri, 2004-04-23 at 12:58 -0500, Jerry Haltom wrote:
> X could have a bulk data transfer protocol (if it doesn't already). 

It does and it's already used by the clipboard (see xincr).

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

Why? Local X server connections are already done via a UNIX domain
socket, and it's still a bottleneck judging from the klipper/gnumeric
bug reports.

> and just a proxy for remote connections. A pipe could connect the two
> local processes directly.

Hmm, back to POSIX IPC school for you ;) The whole point of using SHM
segments is to avoid the overhead of duplicating the data and sending it
over a pipe or socket. The time taken to alter the page tables is lower
than copying a ton of data via the kernel into another process...

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

The current mechanism works fine for remote apps.

> 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

Then the only use case for content negotiation for users like this is
when apps understand different but equivalent formats. I think that's
comparitively rare, and BeOS style translators are probably a better
solution anyway.