[whatwg] Workers feedback
Jonas Sicking
jonas at sicking.cc
Thu Aug 7 18:38:33 PDT 2008
Ian Hickson wrote:
> 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.
This seems to be exactly the same thing as what the spec says now, just
with a different name.
> 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.
I think it's much overly optimistic to think that we will never want to
add port specific stuff to the port object, or worker specific stuff to
the worker object. I just don't have that high confidence in that we can
design these interfaces perfectly in the first version, nor phantom the
features that people will want in future versions.
> 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.
Why is it making them less generic?
One need listed is the ability to in the future add properties that make
sense on one interface but not the other. You are already listing
onerror and onload as not really making sense on a generic MessagePort.
Why does it make things less powerful?
So far it seems like implementors are commenting on wanting this change,
so implementation complexity doesn't seem like a real concern.
> 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?
That only addresses one of the comments listed in my last mail.
/ Jonas
More information about the whatwg
mailing list