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

On Fri, Jun 10, 2011 at 12:50 PM, Travis Leithead <
Travis.Leithead@microsoft.com> wrote:

>
>
> >From: Kenneth Russell [mailto:kbr@google.com], Sent: Thursday, June 09,
> 2011 11:15 PM
> >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
> >> CanvasPixelArray+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-portis
> >*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.
>
> This looks like a mis-reading on my part of step 2 of the postMessage
> algorithm:
>
> "2.If the method was called with a second argument ports and that argument
> isn't null, then, if any of the entries in ports are null, if any
> MessagePort object is listed in ports more than once, ***if any of the
> MessagePort objects listed in ports have already been cloned once
> before,**** or if any of the entries in ports are either the source port or
> the target port (if any), then throw an INVALID_STATE_ERR exception.
>
> Depending on how you look at it, this could be referring to the underlying
> port object, or to the current port instance. Ian is on this thread--I
> assume you now meant purely transfer of ownership?
>
>
> >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.
>
> I guess I disagree on the "elegant" assertion, but that's neither here nor
> there when it comes to spec-ing a behavior.
>
>
> >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.
>
> If this [supporting the object graph and transfer of ownership in-context]
> is an absolute MUST requirement, then the real difference between what we
> are proposing today versus a new API is that the new API is an all-in
> transfer-of-ownership (all applicable objects will be transferred rather
> than cloned). The downside to an all-in API is that as existing objects get
> "transfer-of-ownership" behavior that breaks the new API is non-backwards
> compatible way (e.g., API would transfer ArrayBuffer, but not PixelArray,
> then PixelArray becomes transferrable and existing clients of the API break
> when the new semantics are applied.
>
> This line of reasoning has brought be back to the position that any object
> that wants transfer-of-ownership must opt-in. And the proposed method of
> doing so does exactly that.
>

The new api could only support items with a defined way to do transfer of
ownership. (Note the underlying implementation may not in actuality really
pass around the same memory.) Then there isn't a backwards compatibility
issue.

dave