On Wed, Jun 8, 2011 at 6:26 PM, Kenneth Russell <kbr@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