[whatwg] Workers

Wed Nov 12 15:35:41 PST 2008

(cc'ed whatwg -- sorry if that wasn't what you intended)

On Wed, 27 Aug 2008, Michael Nordman wrote:
> 
> I see... in that case, consider renaming the owner invoked 
> worker.close() method to use a different verb than self.close()... 
> worker.stop() or worker.terminate() or worker.kill() or worker.abandon() 
> or worker.discard()

I've renamed it worker.terminate().

> > > Is it possible for a worker (shared or dedicated) to reload itself?
> >
> > Not currently.
> 
> For dedicated workers, this can effectively be accomplished already by 
> one of the two means of close()ing a worker and then starting a new one 
> and then handing out ports as needed.
> 
> But for shared workers, this is a more interesting question. Provided 
> clients of the shared worker (those that have a reference to it) can be 
> relied on to restart it upon onclose(), reload() would effectively 
> happen. Are there any windows of time where a shared worker executes w/o 
> a client having a reference it?

Yes. Any worker can survive, e.g. if it has timers running, until its 
parent window (or any window that it ever spoke to) closes the document 
it is associated with.

I don't really see the use case for self-reloading. Do scripts self-reload 
in general?

> > > How do workers and appCaches interact?
> >
> > workers are associated with browsing contexts, so they go through the 
> > normal app cache networking changes. This probably interacts badly 
> > with shared workers used from different app caches. We should probably 
> > study this more.
> >
> > Aaron, Maciej, others, do you have opinions on how these should 
> > interact?
> 
> Seems reasonable to spec that dedicated workers are very related to 
> their owner, execute in a child browsing context, and consequently 
> inherit the same appCache.
> 
> Seems reasonable to spec that shared workers are associated with a 
> browsing context that is very distinct from their clients. Akin to an 
> "auxiliary top-level browsing context".

The above seems reasonable...

> Beyond that it gets less clear.
> 
> Do sharedWorker.js documents need a <html manifest='url'> equivalent?

They don't have one today. I don't really want to add one...

> Should a shraredWorker loaded from appCacheA be distinct from a named 
> shared worker loaded from appCacheB or from the network?

That seems like a reasonable possibility too...

I haven't fixed this yet.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'