Re: [worker] Integration of WorkerGlobalScope and AbstractWorker

[Anne van Kesteren]

On Sun, Aug 23, 2015 at 12:23 PM, Bang Seongbeom
bangseongb...@hotmail.com wrote:
 The current spec says that the internal worker scope is WorkerGlobalScope(or
 Dedi-, Shared-), the external is AbstractWorker(or Worker, Shared-.) But it
 destroys consistency with Window object and confuses users with the
 difference of WorkerGlobalScope and AbstractWorker.

Well, I don't think there's much consistency to be gained since it's
quite a bit different. And it's unclear whether consistency with
Window would be good, given all its legacy baggage.


 The global scope Window object can't access to the other Window object
 that's derived from the other origin because of the Same Origin Policy. Like
 this, we can restrict the access by it, not to separate the two objects.

What object would then use to communicate with the other side?


 And it's hard to understand that why can't terminate in WorkerGlobalScope
 and can't close in AbstractWorker. These two methods should be provided
 equally, or not.

Not sure about the rationale for this.


-- 
https://annevankesteren.nl/

[worker] Integration of WorkerGlobalScope and AbstractWorker

[Bang Seongbeom]

The current spec says that the internal worker scope is 
WorkerGlobalScope(or Dedi-, Shared-), the external is AbstractWorker(or 
Worker, Shared-.) But it destroys consistency with Window object and 
confuses users with the difference of WorkerGlobalScope and AbstractWorker.


The global scope Window object can't access to the other Window object 
that's derived from the other origin because of the Same Origin Policy. 
Like this, we can restrict the access by it, not to separate the two 
objects.


And it's hard to understand that why can't terminate in 
WorkerGlobalScope and can't close in AbstractWorker. These two methods 
should be provided equally, or not.