- From: Travis Leithead <Travis.Leithead@microsoft.com>
- Date: Fri, 10 Jun 2011 19:50:14 +0000
- To: "kbr@google.com" <kbr@google.com>
- CC: Andrew Wilson <atwilson@google.com>, Glenn Maynard <glenn@zewt.org>, "Jonas Sicking" <jonas@sicking.cc>, David Levin <levin@chromium.org>, 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>, Ian Hickson <ian@hixie.ch>
>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-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. 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.
Received on Friday, 10 June 2011 19:50:45 UTC