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
