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

On Thu, Jun 9, 2011 at 10:54 PM, Travis Leithead
<Travis.Leithead@microsoft.com> wrote:
> Honestly, there’s something about this whole discussion that just doesn’t
> feel right.
>
>
>
> I looks like we’re trying to graft-in this new concept of transfer of
> ownership into the existing postMessage semantics (i.e., object cloning).
> Any way I try to make it work, it just looks like peaches grafted into an
> apple tree.
>
>
>
> What happened to Jonas’ other proposal about a new API? I’d like to direct
> some mental energy into that proposal.
>
>
>
>>> Complexity comes in many forms and shapes. I much more like the idea
>
>>> of explicit APIs that make it clear what happens and make it hard to
>>> shoot
>
>>> yourself in the foot. Yes, it can involve more typing, but if it results
>>> in more
>
>>> resilient code which contains fewer subtle bugs, then I think we have
>>> designed
>
>>> the API well.
>
>>>
>
>>> / Jonas
>
>
>
> Ex: void postMessageAndTransfer([in] any transferOwnershipToDestination…);
>
>
>
> We’re only talking about a scenario that makes sense primarily for Web
> Workers and applies only to certain types like ArrayBuffer,
> CanvasPixelArray+ImageData, Blob, File, etc., that have large underlying
> memory buffers.
>
>
>
> We don’t really need to support JavaScript objects, arrays, complex graphs,
> etc. at all with the new API (and since the current proposal requires the
> web developer to make an explicit list anyway for the 2nd param to post
> message, it’s no _more_ work to do the same for a new API).
>
>
>
> We could even try to graft MessagePorts into this API, but why? MessagePorts
> are unique in function compared to the other objects we are discussing for
> transfer of ownership (e.g., they facilitate further messaging and can’t be
> re-posted once they are cloned once), and they already have well-defined
> behavior in MessageEvents and SharedWorkers.
>
>
>
> I propose keeping postMessage exactly as it is. Let’s eliminate the
> potential compatibility issues. Let’s not re-write the existing specs (that
> feels like going backwards, not forwards). For transfer of ownership, let’s
> bring this capability on-line through a new API, for the specific scenario
> where it makes sense (Web Workers) and not pollute the current postMessage
> concepts (object graph cloning and port-passing).

Travis,

I disagree with your statement that "MessagePorts are unique in
function compared to the other objects we are discussing for transfer
of ownership". Cloning a MessagePort per
http://dev.w3.org/html5/postmsg/#clone-a-port is *exactly*
transferring its ownership to the other side. The reason that a
MessagePort object can only be cloned once is that its ownership has
been transferred. There is no restriction in the current specification
preventing the cloned port from being transferred to a new owner via
postMessage.

The current proposal on the table is 100% backward compatible in
signature and semantics, and is an elegant generalization of the
slightly over-specialized MessagePort mechanism into the desired
transfer of ownership mechanism.

In any other API I would personally want exactly postMessage's
capability of sending full JavaScript object graphs over the wire,
while still being able to transfer ownership of some of the objects
contained within, to be able to add some structure to the messages
being sent. I would not want to artificially restrict the API to only
be able to send certain types of objects.

-Ken

Received on Friday, 10 June 2011 06:15:05 UTC