Re: Workers

Ian Hickson wrote:
> On Sun, 20 Jul 2008, Andrew Fedoniouk wrote:
>> But intention is to isolate Worker from the Document and rest of the 
>> DOM, correct?
> 
> No, the intention is to isolate the script running inside the worker from 
> the Document object, not to isolate the actualy implementation.
> 

I see. So the script will have no such things as 'window' and 'document'
accessible to it. But you've mentioned that you want to keep 'window'...
in script, correct?

If it will have 'window' then that 'window' will be an object of 
different class than traditional 'window'. E.g. there will not be such 
thing as window.document. Correct?

What methods of the 'window' you want keep, BTW?
Such things as alert() shall not be available for the script in Worker.
It should not use UI in any manner. Am I right?

> 
>> It appears as I am getting term "browsing context" wrong.
>> Is it something that can be expressed in terms of formal interface definition
>> like:
>>    interface BrowsingCtx { ... }
>> or is it some abstraction behind the scene?
> 
> A browsing context is basically a tab or window or iframe.
> 

Ah, OK. So it is something under the hood of scripting.
Like Worker lives inside operational environment (or inherits that 
environment) of its owner. That means for example that Worker works on 
the same level of security as its owner. Correct?

> 
>> I think that term 'thread' shall be used in the specification instead of 
>> "completely separate and parallel execution environment".
> 
> It was suggested that using the term "thread" would imply state sharing, 
> since most threading mechanisms do indeed share state. Here it's more like 
> a separate process than a separate thread.
> 


-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Sunday, 20 July 2008 23:56:27 UTC