14093 – 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

This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 14093 - 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

Summary: Just to throw out an idea, to allow use of the XML parser, and alert() for de...

Status:	RESOLVED DUPLICATE of bug 14086

Alias:	None

Product:	WebAppsWG
Classification:	Unclassified
Component:	Web Workers (editor: Ian Hickson) (show other bugs)
Version:	unspecified
Hardware:	Other other

Importance:	P3 normal
Target Milestone:	---
Assignee:	Ian 'Hixie' Hickson
QA Contact:	public-webapps-bugzilla

URL:	http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2011-09-08 20:58 UTC by contributor
Modified:	2011-09-13 12:19 UTC (History)
CC List:	3 users (show)

See Also:

Attachments

Description contributor 2011-09-08 20:58:16 UTC

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

Comment 1 Ian 'Hixie' Hickson 2011-09-10 04:47:37 UTC

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.

Comment 2 Simon Pieters 2011-09-13 12:19:36 UTC


*** This bug has been marked as a duplicate of bug 14086 ***