On Tue, Jun 21, 2011 at 9:27 PM, Glenn Maynard <glenn@zewt.org> wrote:
> 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.
>
If it doesn't throw, doesn't that introduce the backwards compat issue when
something new is supported that wasn't before?
>
> 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
>