On Wed, Jun 8, 2011 at 6:26 PM, Kenneth Russell <k...@google.com> wrote:
> > Thinking about this more, that port could be sent as the data > attribute of the event instead of the empty string. Then the ports > attribute on MessageEvent could be safely deprecated. > > -Ken > > So a number of different variations have floated around, and I have some concerns: 1) I'm not completely sure I understand what the new postMessage() semantics look like. Since cloning a port is a destructive operation, I like the fact that the current postMessage() API requires the developer to explicitly pass a list of ports to clone. If we shift to a paradigm where merely referencing a port from the object graph is sufficient to do a destructive clone of that port, I'm concerned that this will lead to very-difficult-to-debug issues for developers. So I would say that there is value to still requiring the developer to pass a separate "objectsToTransfer" array, even if we automagically fixup references to those transferred objects within the object graph. 2) Rather than having some mix of deprecated attributes on MessageEvent to support SharedWorkers, I'd rather just change onconnect() to take a distinct event type that has a non-deprecated ports attribute - I've never been particularly clear why we're reusing the MessageEvent interface for SharedWorker connect events anyway. Since Safari and Chrome have supported SharedWorkers for well over a year now, I would be careful about changing this interface in a non-backwards-compatible manner - however, if we are not concerned with backwards compatibility, I would change this ConnectEvent to just have a port attribute that references a single port rather than a ports[] attribute that references an array that always contains a single port. -atw