I guess I'm not a big fan of removing ports[] from the connect event unless we also remove it from MessageEvent entirely. All the same arguments you've posed here also apply to MessageEvents in general, so I'd be opposed to removing it in only one place. I'm somewhat OK with keeping ports[] but also exposing the port through the |source| attribute, although "it's OK to put different objects in |source| as long as they all expose an API called postMessage()" feels inelegant to me - at least it's backwards compatible. If we're going to make a non-backwards-compatible change (and I'm not convinced that we should), I think my preferred solution would be along the lines of the change described by Jonas earlier - leave |source| alone, get rid of the |ports| attribute from MessageEvent entirely, and expose the port in the connect event via the |data| attribute. This is more closely aligned with the new Transferrable support in postMessage() anyway. -atw On Wed, Apr 11, 2012 at 2:05 AM, Simon Pieters <simonp@opera.com> wrote: > On Wed, 11 Apr 2012 09:29:53 +0200, Jonas Sicking <jonas@sicking.cc> > wrote: > > I would prefer to expose the port through .source even if we can't get >> rid of .ports[0] right now. >> > > I think the longer we wait with removing it, the more legacy will be > created that relies on its existence. > > > The ports property is basically useless >> right now except for this one instance and so while I agree that there >> might be some confusion in the short term, it doesn't seem like it >> would be a compatibility problem, and long term it seems like a win >> that authors wouldn't have to worry about the property at all. It >> might continue to work if we decide that it's needed for back compat, >> but it seems like we eventually would be able to get rid of it given >> how new the property still is. >> >> / Jonas >> > > > -- > Simon Pieters > Opera Software >
Received on Wednesday, 11 April 2012 17:16:34 UTC