Honestly, there's something about this whole discussion that just doesn't feel right.
I looks like we're trying to graft-in this new concept of transfer of ownership into the existing postMessage semantics (i.e., object cloning). Any way I try to make it work, it just looks like peaches grafted into an apple tree. What happened to Jonas' other proposal about a new API? I'd like to direct some mental energy into that proposal. >> Complexity comes in many forms and shapes. I much more like the idea >> of explicit APIs that make it clear what happens and make it hard to shoot >> yourself in the foot. Yes, it can involve more typing, but if it results in >> more >> resilient code which contains fewer subtle bugs, then I think we have >> designed >> the API well. >> >> / Jonas Ex: void postMessageAndTransfer([in] any transferOwnershipToDestination...); We're only talking about a scenario that makes sense primarily for Web Workers and applies only to certain types like ArrayBuffer, CanvasPixelArray+ImageData, Blob, File, etc., that have large underlying memory buffers. We don't really need to support JavaScript objects, arrays, complex graphs, etc. at all with the new API (and since the current proposal requires the web developer to make an explicit list anyway for the 2nd param to post message, it's no _more_ work to do the same for a new API). We could even try to graft MessagePorts into this API, but why? MessagePorts are unique in function compared to the other objects we are discussing for transfer of ownership (e.g., they facilitate further messaging and can't be re-posted once they are cloned once), and they already have well-defined behavior in MessageEvents and SharedWorkers. I propose keeping postMessage exactly as it is. Let's eliminate the potential compatibility issues. Let's not re-write the existing specs (that feels like going backwards, not forwards). For transfer of ownership, let's bring this capability on-line through a new API, for the specific scenario where it makes sense (Web Workers) and not pollute the current postMessage concepts (object graph cloning and port-passing).
