Ian Hickson wrote:
On Wed, 6 Aug 2008, Aaron Boodman wrote:
I am opposed to the utils object. I don't see any precedent for this
anywhere, and it just feels ugly to me. I liked it the way you had it
before, with these APIs in a shared base interface.
Ok. I don't have an opinion on this. Jonas?
In the absence of any arguments either way, my default would be put it all
on the global object; clashes are manageable, the Window object does it
that way, and there are enough things that we kinda want to put on the
global scope anyway (the core worker stuff) that it's not a clear that the
gain is huge.
I don't feel very strongly about this right now. It's something we
started debating at mozilla and I think we'll debate it a bit more
before coming to a conclusion. I'm fine with putting it in the global
scope for now. Sorry, i didn't mean to ask for an immediate action on
this yet.
That's also one reason why I like having a separate Worker object and
having the two-step process of creating the worker, then sending it a
message. It means that creating a new channel to a worker is always the
same.
It seems that designing the API to add extra steps is a bad thing
generally speaking. :-)
Though in the vast majority of cases only the first step is needed. A
second step is only needed in the very complex use cases of:
* Having sibling workers talk directly to each other.
* Having a worker talk directly to a frame from a different origin.
* Having a worker shared across different instances of the app.
I think that 'load', 'error', and 'unload' could go on the worker. As
far as I can tell, the only thing 'load' and 'error' are used for is
telling the creator of a worker that the worker loaded or failed to
load. In that case, it seems wrong to throw them on MessagePort, since
MessagePorts are also used for many other things.
I also still think that Workers could have their own sendMessage. The
messages sent to this would be delivered to the worker as 'message'
events targeted at WorkerGlobalObject (eliminating the need for
onconnect?). This would make Workers and postMessage very similar to
Window and postMessage, which seems nice to me.
How's this for a compromise:
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.
Would that work for you?
I thought about that, but what happens if you pass such an object to
postMessage? Throws an exception? Only the parts of the API that is a
MessagePort dies?
One solution I thought about is to have a base interface such as:
interface MessagePort {
void postMessage(...);
attribute EventListener onmessage;
...
}
Then have
interface Worker : MessagePort {
bool isShared();
<worker specific stuff>
}
interface PipePort : MessagePort {
attribute Window ownerWindow;
<Pipe specific stuff>
}
And then make the APIs that we want to allow passing around pipe-ends
take a PipePort object.
The result is basically that workers are separate objects from what's
returned for (new MessagePipe()).port1, but they share some API.
- Should import() accept an array of URLs, so that the UA can fetch
them in parallel if it has the ability to do that?
We could do that if you like. Is it needed?
With the connection limits being upped in all the browsers, I think this
would be a good thing to have from the beginning.
Fair enough. Should they be run in whatever order they load in or should
they be run in the order given on the aguments?
Yes. Another thing is that this function should probably return void and
always throw if something goes wrong. I doubt that having the server
return a 404 is expected enough that just returning 'false' will keep
the program executing fine.
/ Jonas
