[whatwg] workers

[Jonas Sicking]

Hi Guys,

Sorry about the slow feedback, has been on vacation most of the time.

So first off I don't think we can remove the ability to pass
MessagePorts around. This ability exists in Window.postMessage already
per spec so nothing that the workers spec does can change that. Also, if
we think the "pass-around-ability" of ports affect how much we want to
use them, punting the pass-around-ability to the second version of the
spec shouldn't really affect how we design the API as we'll arrive at
the second version sooner or later.

So given that, I prefer the current API. I think that for the common
case of non-shared workers it makes for a simpler API. The fact that you 
argue that there should be a catch-all global onmessage inside the 
worker seems to indicate that using onconnect is lacking somewhere.

I agree with the benefit of keeping shared vs. non-shared workers as 
similar as possible. However I feel that the complexities that come with 
always using ports for non-shared workers outweighs it.

/ Jonas

Aaron Boodman wrote:
> Ping? Thoughts? Anyone?
> 
> Jonas, I know you are the one most likely to be affected by this in
> the near term. Thoughts?
> 
> I know you are generally in favor of something close to the current
> Gears API, and generally against the concept of MessagePorts.
> 
> But I think introducing a MessagePort object is important for two main reasons:
> 
> - Makes the interface very similar for dedicated and shared workers,
> which I think makes it easier to use both.
> - Makes it easy for developers to set up multiple 'conversations'
> (ports) between clients and workers by calling connect(). The lack of
> this is a key annoyance with current Gears workers
> 
> Note that I have suggested punting on passing ports around initially,
> which I feel like is the harder part.
> 
> On Mon, Sep 15, 2008 at 4:52 PM, Chris Prince <cprince at google.com> wrote:
>> I think your proposal nearly works for window.postMessage() too.  If
>> you move 'onconnect' and 'connect()' into a MessageReceiver interface
>> [better name TBD], and make Worker and Window both inherit from
>> MessageReceiver, do you end up with a unified messaging model?
> 
> Maybe. One wrinkle is that Window's postMessage is a little different,
> because you have to pass the origin you're targeting
> (http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting).
> 
> I do think that the 'conversation' concept that MessagePorts represent
> is also useful for cross-window communication and it would nice to
> generalize these as much as possible.
> 
> - a