Transferencia INCR (X11)
La forma que tiene el ICCCM de entregar una selección demasiado grande para una sola propiedad: por trozos, con un apretón de manos por trozo y otras tantas ocasiones para que algo falle.
Cuando un programa pide una selección de X, el propietario deposita la respuesta en una propiedad de la ventana del solicitante. Las propiedades viajan como peticiones de X, y en el protocolo clásico una petición tenía un tope de 256 KB; un documento entero en el portapapeles no cabía. El ICCCM lo resuelve con el tipo INCR: en vez de datos, el propietario escribe un número, una cota inferior de cuántos bytes vienen, y el solicitante entiende que llegará más.
Entonces empieza el baile. El solicitante borra la propiedad, el propietario escribe el primer trozo, el solicitante lo lee y lo borra, el propietario espera el PropertyNotify del borrado antes de escribir el siguiente, y un trozo vacío marca el final. Ambas partes tienen que escuchar eventos de propiedad en mitad de una transferencia, y ambas necesitan un tiempo límite por si la otra muere a medio camino. Es un fragmento de protocolo que muchos clientes implementan con descuido o no implementan, y ahí está la explicación del clásico fallo de que un pegado grande sale vacío mientras uno pequeño funciona. BIG-REQUESTS subió el techo, pero INCR sigue ahí porque el límite nunca desapareció del todo.