W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: Shared workers - use .source instead of .ports[0] ?

From: Andrew Wilson <atwilson@google.com>
Date: Wed, 11 Apr 2012 10:16:01 -0700
Message-ID: <CAArhhitNP1B-p9zzSBMtOWZ_SAL1-gfWy=ja5mqo00TTVyqk0g@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: Jonas Sicking <jonas@sicking.cc>, David Levin <levin@google.com>, Jarred Nicholls <jarred@webkit.org>, "public-webapps@w3c.org" <public-webapps@w3c.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:51 GMT