(Can you please reset your font?)
On Fri, Jun 10, 2011 at 1:54 AM, Travis Leithead <
Travis.Leithead@microsoft.com> wrote:
> We don’t really need to support JavaScript objects, arrays, complex
> graphs, etc. at all with the new API
>
Strongly disagree. I should be able to transfer objects naturally with the
existing API, with the same flexibility:
postMessage([
{ frameData: computedArrayBuffer, frameId: 1, complexNestedObject: obj1
},
{ frameData: secondComputedArrayBuffer, frameId: 2, complexNestedObject:
obj2 }
], [computedArrayBuffer, secondComputedArrayBuffer]);
Using a whole separate API that can't handle everything that structured
clone can would be an unnecessarily limiting kludge, forcing the receiver to
piece together transferred objects and their associated cloned objects,
which would be received in separate messages.
This proposal is also completely transparent to the receiving side, so an
API exposed through messages can make use of object transfer without
affecting users of the 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).
>
It's a lot more work for the developer if he has to use separate APIs for
transferred objects and everything else.
(Also, a minor side proposal is to allow including object constructors, so
you can say things like postMessage(obj, [ArrayBuffer]). That would allow
developers to avoid having to write an explicit list.)
--
Glenn Maynard