W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

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

From: David Levin <levin@chromium.org>
Date: Tue, 21 Jun 2011 22:25:29 -0700
Message-ID: <BANLkTimoWcC3fj_Fp12uSuiHTNbnVyBgTg@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, Andrew Wilson <atwilson@google.com>, Kenneth Russell <kbr@google.com>, Arthur Barstow <art.barstow@nokia.com>, Dmitry Lomov <dslomov@google.com>, ben turner <bent.mozilla@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Travis Leithead <Travis.Leithead@microsoft.com>
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
Received on Wednesday, 22 June 2011 05:26:13 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:32 UTC