On Tue, Jun 21, 2011 at 9:27 PM, Glenn Maynard <gl...@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 >