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

What happens if an object is included in the second list that doesn't
support transfer?  Ian said that it would throw, but I'm not sure that's
best.

Suppose Firefox N supports transferring ArrayBuffer, and Firefox N+1 adds
support for transferring ImageData.  Developers working with Firefox N+1
write the following:

   postMessage(obj, [obj.anArrayBuffer, obj.anImageData]);

On Firefox N+1, both objects will be transferred, mutating the sender's
copy.  In Firefox N, only the ArrayBuffer will be transferred, and the
ImageData is cloned.  Developers don't need to write wrappers to scan
through the list and remove objects which don't support transfer.  They
don't have to test code with every version of browsers to make sure that
their transfer lists are created correctly for every possible combination of
supported object transfers.  They just list the objects which they're
prepared to have mutated and will discard after sending the message.

>  postMessage([thisArrayBufferIsCopied, thisPortIsTransferred],
>              [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).

I don't think the ports array should be expanded to include all transferred
objects.  This would turn the list into part of the user's messaging
protocol, which I think is inherently less clear.  Protocols using this API
will be much cleaner when they're based on a single object graph.

I'd recommend that the "ports" array contain only the transferred ports, for
backwards-compatibility; anything else transferred should be accessed via
the object graph.

This also means that the transfer list has no visible effects to receivers.
 Senders can choose to add or not add objects for transfer based on their
needs, without having to worry that the receiver of the message might depend
on the transfer list having a particular format (with the exception of
message ports).  Having the transfer list both act as part of the messaging
protocol *and* change the side-effects for the sender will create conflicts,
where you'll want to clone (not transfer) an object but be forced to include
it in the transfer list to satisfy the receiver.

-- 
Glenn Maynard