14093 2011-09-08 20:58:16 +0000 Just to throw out an idea, to allow use of the XML parser, and alert() for debugging, one could implement web workers as simply another open page in the browser, with full access to the DOM, etc, with the ability to communicate to the 'parent' by posting 2011-09-13 12:19:36 +0000 1 1 1 Unclassified WebAppsWG Web Workers (editor: Ian Hickson) unspecified Other other RESOLVED DUPLICATE 14086 http://www.whatwg.org/specs/web-apps/current-work/#top P3 normal --- 1 contributor ian ian mike public-webapps public-webapps-bugzilla oldest_to_newest 56558 0 contributor 2011-09-08 20:58:16 +0000 Specification: http://www.w3.org/TR/2011/WD-workers-20110901/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: Just to throw out an idea, to allow use of the XML parser, and alert() for debugging, one could implement web workers as simply another open page in the browser, with full access to the DOM, etc, with the ability to communicate to the 'parent' by posting messages only. The parent could specify to the browser that the new page should not be made visible to the user (in the use case where the new page will be processing AJAX replies using the DOM Parser) or visible (in the use case where the developer is debugging the web worker and wants to see calls to window.alert()). So a web worker is like another tab in the browser that can communicate with the spawning tab via messages only. So web worker API is really just a intra-page communication interface with pages able to open new pages and keep them invisible. Tabs in a browser are like independent processes. And it seems web-workers is more about processes than threads. This allows one web application (process) to spawn another and talk to it. This will not interfere with or conflict with the idea of having javascript have threads in the future, but would complement it. With multi-processors becoming common, I think javascript will soon follow C++ in adding thread support. Posted from: 199.89.158.132 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2 56590 1 ian 2011-09-10 04:47:37 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: The reason workers don't have a DOM is that some browsers implement workers as threads, and yet browsers do not have thread-safe DOM implementations (they have global non-threadsafe state in their DOM implementations). Many browsers don't have a way to run multiple pages in separate processes yet still have them communicate. 56743 2 zcorpan 2011-09-13 12:19:36 +0000 *** This bug has been marked as a duplicate of bug 14086 ***