Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]

So the proposal that seems to address the most concerns raised in this 
thread would be to have postMessage() work like this:

   postMessage({ object }, [ array ]);

...with it resulting in an event that contains both {object} and [array], 
where everything in the array is transferred, and everything in the object 
is by default cloned unless it's in both the {object} and the [array] in 
which case the transferred copy is used instead.

That way you can keep doing the simple thing to send a port:

   postMessage('vend-reply', [port]);

...and you can pass array buffers in complex data structures as copies:

   postMessage({ data: arrayBuffer });

...and you can send them as clones without losing the structure, though 
you have to walk your structure to list all the objects you care about:

   postMessage({ data: arrayBuffer }, [arrayBuffer]);

...but you don't _have_ to do something like this to send a port:

   postMessage(['vend-reply', port], [port]);

...which seems a bit ugly.

It also means you can both transfer and copy, if that's what you want:

   postMessage([thisArrayBufferIsCopied, thisPortIsTransferred], 

This also has the benefit of being backwards-compatible, at least if I 
keep an attribute on the event on the other side called "ports" that 
includes the transferred objects (maybe another attribute should be 
included that also returns the same array, since 'ports' would now be a 
confusing misnomer). Alternatively, we can rename 'ports' to something 
else and just have WebKit support 'ports' for legacy reasons. If we do 
this I can also change the 'connect' event to make more sense.


Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 20 June 2011 22:54:38 UTC