[whatwg] Workers feedback

On Thu, 7 Aug 2008, Jonas Sicking wrote:
> > 
> > We make the createWorker() methods return a Worker object, but the 
> > Worker object _inherits_ from MessagePort. So effectively it is a 
> > port, but we can move the onload and onerror stuff to the Worker 
> > object instead of having them on all MessagePorts.
> 
> I thought about that, but what happens if you pass such an object to
> postMessage?

It would just get cloned as usual.

The only things that a Worker object would have that a regular MessagePort 
wouldn't is the onload and onerror things, and they're only relevant until 
the point where you have a connection, so losing them when you clone the 
port is fine.


> One solution I thought about is to have a base interface such as:
> 
> interface MessagePort { ... }
> 
> Then have
> 
> interface Worker : MessagePort {
>    bool isShared();
>    <worker specific stuff>
> }
> 
> interface PipePort : MessagePort {
>    attribute Window ownerWindow;
>    <Pipe specific stuff>
> }

ownerWindow is gone. There's no pipe-specific stuff that wouldn't also 
apply to a worker. There's no worker-specific stuff once the channel has 
been established.

What's the use case for isShared()? What does it do?


I really don't like this idea of making Workers less generic. There's no 
need for it as far as I can tell, and all it does is make things less 
powerful while actually increasing implementation complexity.

Would it be better if instead of createWorker() we called the method 
connectToWorker(), and it creates it as well if the worker is unnamed or 
doesn't yet exist? That would resolve the issue of what looks like a 
constructor not returning an object representing what it constructs?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 7 August 2008 13:37:20 UTC