[whatwg] Workers feedback

[Alexey Proskuryakov]

Nov 14, 2008, в 2:30 AM, Ian Hickson написал(а):

> I believe that the idea that the API for shared and dedicated workers
> should be the same is misguided. The spec used to make the two cases
> identical. The result was confusion, and the dedicated case was much  
> more
> complex than necessary.

This is the strongest argument for having separate interfaces of all  
presented, but in my opinion, it misses some important data points:
- Was introducing a new interface the only way to resolve the  
confusion? Maybe renaming a method or two would have had a positive  
effect?
- Did it help resolve the confusion?
- What kind of danger the confusion was? Would authors write under- 
performing and unreliable code, or refuse to use such a cumbersome API  
at all? Or was is just a momentary delay for some, resolved quickly  
and harmlessly?

I don't remember any of these discussed here.

> Shared workers and dedicated workers are fundamentally different and  
> have
> different needs, and we should expose these needs in ways optimised  
> for
> the two cases.
>
> The basic need is that dedicated workers be able to have a two-way
> communication channel with their creators, and shared workers be  
> able to
> have a two-way communication with each user of the worker.

I think that this argument is false. It is normal for a single API to  
support multiple use cases.

Replace Worker with XMLHttpRequest, and we end up with separate  
interfaces for GET and POST.

<skipped code samples>

> For dedicated workers though that's way more complexity than we want  
> to
> require of authors -- why do they have to listen for a port when there
> will always be exactly one? So it makes sense to use

It is not true that there will always be one - additional ports can be  
passed in via postMessage().

> Now, we've at this point made the two different already, so as to  
> simplify
> the dedicated worker, so we could (and the spec does) make the  
> dedicated
> worker even simpler while we're at it.

Returning to the XMLHttpRequest example, we really can combine open()  
and send() for XMLHttpRequestGET, but not for XMLHttpRequestPOST.  
Generally, the interfaces can be very different if we try to.

> One way to do that is to bury the ports into the Worker and global  
> scope
> objects. If we do one side, though, we have to do the other, because  
> it
> would be really weird to have a message channel that half-acts like a
> two-port channel and half doesn't.

I agree.

> For example, if we bury it, we
> shouldn't expose .close(), since it's better for the worker to be  
> closed
> using the actual .close() or .terminate() API, but if we only "bury"  
> one
> side, then one end could close the pipe and not the other, and we'd  
> have
> to make sure we expose .onclose on the buried end, and so forth.

I agree that if we have a direct interface for messaging on one side,  
we should have it on both sides.

> So, we end up with what the spec has now.
>
> I think what we have now is better than making dedicated and shared
> workers superficially the same (as the spec used to be, and as the  
> people
> involved in this thread argued was bad) is more confusing for authors.

I'd be more that happy with a separate interface if the objects  
actually behaved differently. One example of a good reason to have  
separate interfaces was recently proposed here: shared workers should  
outlive their creators. This is the sort of difference that would make  
having a separate API reasonable, in my opinion.

> At this point, if the only arguments for changing the API are "it's
> confusing for authors", then I'd rather not change the API. We got to
> where we are today by carefully considering what would be better for
> authors. We could continue going back-and-forth and reverting earlier
> decisions until the cows come home, but I see no benefit to doing so.


I don't think it's inappropriate to continue back-and-forth until  
there is at least one reasonably complete implementation validating  
the spec. Currently, the Mozilla implementation is very different in  
spirit, not supporting MessagePorts at all.

>> * I still don't buy the utility of passing around MessagePorts, so I
>> suggest we table that for v2. It can always be added back later.
>
> Since they so drastically affect the API design, I think putting  
> them off
> is a mistake. We might end up constraining ourselves in unobvious  
> ways.

I agree.

- WBR, Alexey Proskuryakov