W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

[Bug 14093] New: 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

From: <bugzilla@jessica.w3.org>
Date: Thu, 08 Sep 2011 20:58:16 +0000
To: public-webapps@w3.org
Message-ID: <bug-14093-2927@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14093

           Summary: 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
           Product: WebAppsWG
           Version: unspecified
          Platform: Other
               URL: http://www.whatwg.org/specs/web-apps/current-work/#top
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Web Workers (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: contributor@whatwg.org
         QAContact: member-webapi-cvs@w3.org
                CC: mike@w3.org, public-webapps@w3.org


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

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Thursday, 8 September 2011 20:58:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT