[kevincox]

I think you are right but it is still an optimization in the common case.

1. If the owning app doesn't need it anymore it does need to keep it around until the clipboard is replaced, but this is likely still cheaper than copying. (For example if you are copying images you just need to reference-count the image, or if you are copying a table in an app with an undo history you are holding that data anyways, you just need to know how to rebuild the old version for the copy).

2. If the owning app is offering to do conversions (for example text/csv or text/html for a table) it only needs to hold one version in memory.

Of course this does add a lot of complexity to do it "well". However the app can always start with a simple implementation (just make a copy/reference count internally) then migrate to a better implementation when it makes sense.

It does seem to me that a hybrid implementation may have been the best. Apps can send data to the compositor (maybe via a sealed memfd) or just tell the compositor to ask for the data when it wants it. Maybe this could even be done per-content-type so that for example the app can send the `text/csv` to the compositor but if someone asks for `text/html` it can read the `text/csv` from the compositor then send back the `text/html`. But that would be an edge case, and still has a problem with closing applications. I guess when the application closes it can either 1. Upload the other content-types proactively before shutting down or the compositor just drops those types off of the clipboard leaving only the types that it holds itself.