Re: [whatwg] Workers proposal
On Wed, 20 Aug 2008, Jonas Sicking wrote: Do we really need the SharedWorker interface. I.e. couldn't we just return a MessagePort? We could. It would mean either putting onerror on all message ports, or not reporting error information for shared workers. Actually even if we did put onerror on ports, it would be difficult to define which ports actually get the error events. It would also mean not using a constructor, but that's fine. Finally, it would make extending the interface later much harder if we found that it was useful to allow different users of the shared worker to control something. Anyone else have any opinions on this? This would probably require that we use a factory function rather than a constructor, like getPortForSharedWorker or some such. In other words, do we really need onclose and onerror for shared workers (onerror seems to make some sense, onclose i'm less sure about). I don't mind dropping them. I think startConversation makes as much sense on shared workers as dedicated ones, so moving that API up to Worker/WorkerGlobalScope seems like a good idea. startConversation is on the port(s) in the shared worker case. I'm not sure what it would mean on the worker or global scope in the shared case, since there's no target without the port in that case. If we keep the constructors (see first paragraph), I would prefer the syntax new Worker over new DedicatedWorker. That's fine, I can change the base to be AbstractWorker and then have Worker and SharedWorker as the interfaces inheriting from it. I'll wait for slightly more input and then update the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers proposal
Ian Hickson wrote: On Wed, 20 Aug 2008, Jonas Sicking wrote: Do we really need the SharedWorker interface. I.e. couldn't we just return a MessagePort? We could. It would mean either putting onerror on all message ports, or not reporting error information for shared workers. Actually even if we did put onerror on ports, it would be difficult to define which ports actually get the error events. It would also mean not using a constructor, but that's fine. Finally, it would make extending the interface later much harder if we found that it was useful to allow different users of the shared worker to control something. Anyone else have any opinions on this? Yeah, I don't feel strongly either way here. It feels cleaner to not have separate SharedWorker instances for each user of a shared worker, but there are also downsides with not doing that (like onerror and other future properties that we might want). So I'm fine either way. I think startConversation makes as much sense on shared workers as dedicated ones, so moving that API up to Worker/WorkerGlobalScope seems like a good idea. startConversation is on the port(s) in the shared worker case. I'm not sure what it would mean on the worker or global scope in the shared case, since there's no target without the port in that case. Ah, of course. If we keep the constructors (see first paragraph), I would prefer the syntax new Worker over new DedicatedWorker. That's fine, I can change the base to be AbstractWorker and then have Worker and SharedWorker as the interfaces inheriting from it. Sounds good to me. / Jonas
Re: [whatwg] Workers proposal
On Wed, Aug 20, 2008 at 5:36 PM, Ian Hickson [EMAIL PROTECTED] wrote:
I've received feedback from a number of people requesting a rethink to the
API for creating and communicating with workers.
Here is a skeleton of a new proposal. It makes the following changes:
* Shared workers and dedicated workers get their own interfaces,
inheriting from a common base interface, both for the global scope
objects and for the objects returned when they are created.
* Shared workers get a port per connection. Dedicated workers don't get a
port, but they have a convenience method on the worker and on the
worker's global object that allows for easy creation of ports to send
threaded messages (direct replies).
* Uses constructors instead of factory methods to create workers.
* Removes 'onload' from the Worker objects.
* Renamed onunload to onclose throughout.
* Removes the closing boolean.
* Adds a way to kill a dedicated worker.
OUTSIDE
// (abstract, never instantiated)
[NoInterfaceObject] interface Worker {
attribute EventListener onerror; // invoked if the worker fails to start
attribute EventListener onclose; // invoked if the worker closes
};
interface DedicatedWorker : Worker {
void close(); // kills the worker immediately, without cleanup
Is the shutdown sequence initiated by this method call different then the
shutdown sequence initiated by a call to self.close() from within the worker
itself? The comment hints that it is... if so why?
// these all work the same as on MessagePorts:
attribute EventListener onmessage; // receives messages from the worker
boolean postMessage(in DOMString message);
boolean postMessage(in DOMString message, in MessagePort, port);
MessagePort startConversation(in DOMString message);
};
interface SharedWorker : Worker {
readonly attribute MessagePort port; // local end of channel to worker
};
INSIDE
// (abstract, never instantiated)
[NoInterfaceObject] interface WorkerGlobalScope {
void close();
attribute EventListener onclose;
readonly attribute WorkerGlobalScope self;
readonly attribute WorkerLocation location;
// also implements everything on WorkerUtils
};
[NoInterfaceObject] interface DedicatedWorkerGlobalScope :
WorkerGlobalScope {
// these all work the same as on MessagePorts:
attribute EventListener onmessage; // receives messages from the owner
boolean postMessage(in DOMString message);
boolean postMessage(in DOMString message, in MessagePort, port);
MessagePort startConversation(in DOMString message);
};
[NoInterfaceObject] interface DedicatedWorkerGlobalScope :
WorkerGlobalScope {
attribute EventListener onconnect; // called by createSharedWorker()
readonly attribute DOMString name;
};
CREATING WORKERS
To created workes, use constructors:
var worker = new DedicatedWorker(url);
var service = new SharedWorker(name, url);
Is it possible for a worker (shared or dedicated) to reload itself?
Comments?
How do workers and appCaches interact?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers proposal
This is looking great. A few comments though (of course :) )
Do we really need the SharedWorker interface. I.e. couldn't we just
return a MessagePort? This would probably require that we use a factory
function rather than a constructor, like getPortForSharedWorker or
some such. In other words, do we really need onclose and onerror for
shared workers (onerror seems to make some sense, onclose i'm less sure
about).
I think startConversation makes as much sense on shared workers as
dedicated ones, so moving that API up to Worker/WorkerGlobalScope seems
like a good idea.
If we keep the constructors (see first paragraph), I would prefer the
syntax new Worker over new DedicatedWorker.
/ Jonas
Ian Hickson wrote:
I've received feedback from a number of people requesting a rethink to the
API for creating and communicating with workers.
Here is a skeleton of a new proposal. It makes the following changes:
* Shared workers and dedicated workers get their own interfaces,
inheriting from a common base interface, both for the global scope
objects and for the objects returned when they are created.
* Shared workers get a port per connection. Dedicated workers don't get a
port, but they have a convenience method on the worker and on the
worker's global object that allows for easy creation of ports to send
threaded messages (direct replies).
* Uses constructors instead of factory methods to create workers.
* Removes 'onload' from the Worker objects.
* Renamed onunload to onclose throughout.
* Removes the closing boolean.
* Adds a way to kill a dedicated worker.
OUTSIDE
// (abstract, never instantiated)
[NoInterfaceObject] interface Worker {
attribute EventListener onerror; // invoked if the worker fails to start
attribute EventListener onclose; // invoked if the worker closes
};
interface DedicatedWorker : Worker {
void close(); // kills the worker immediately, without cleanup
// these all work the same as on MessagePorts:
attribute EventListener onmessage; // receives messages from the worker
boolean postMessage(in DOMString message);
boolean postMessage(in DOMString message, in MessagePort, port);
MessagePort startConversation(in DOMString message);
};
interface SharedWorker : Worker {
readonly attribute MessagePort port; // local end of channel to worker
};
INSIDE
// (abstract, never instantiated)
[NoInterfaceObject] interface WorkerGlobalScope {
void close();
attribute EventListener onclose;
readonly attribute WorkerGlobalScope self;
readonly attribute WorkerLocation location;
// also implements everything on WorkerUtils
};
[NoInterfaceObject] interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
// these all work the same as on MessagePorts:
attribute EventListener onmessage; // receives messages from the owner
boolean postMessage(in DOMString message);
boolean postMessage(in DOMString message, in MessagePort, port);
MessagePort startConversation(in DOMString message);
};
[NoInterfaceObject] interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
attribute EventListener onconnect; // called by createSharedWorker()
readonly attribute DOMString name;
};
CREATING WORKERS
To created workes, use constructors:
var worker = new DedicatedWorker(url);
var service = new SharedWorker(name, url);
Comments?
