html5/spec-ja/.workers-spec.en.html


<html lang=en-US-x-hixie>
 <head>
  <title>Web Workers</title>
  <link href="/style/specification" rel=stylesheet>
  <link href="/images/icon" rel=icon>

 <body class=draft>
  <div class=head>
   <p><a class=logo href="http://www.whatwg.org/" rel=home><img alt=WHATWG
    src="/images/logo"></a></p>

   <h1 id=web-workers>Web Workers</h1>

   <h2 class="no-num no-toc" id=draft>Draft Recommendation &mdash; 16 July
    2008</h2>

   <p>You can take part in this work. <a
    href="http://www.whatwg.org/mailing-list">Join the working group's
    discussion list.</a></p>

   <p><strong>Web designers!</strong> We have a <a
    href="http://blog.whatwg.org/faq/">FAQ</a>, a <a
    href="http://forums.whatwg.org/">forum</a>, and a <a
    href="http://www.whatwg.org/mailing-list#help">help mailing list</a> for
    you!</p>

   <dl>
    <dt>This version:

    <dd><a
     href="http://www.whatwg.org/specs/web-workers/current-work/">http://www.whatwg.org/specs/web-workers/current-work/</a>

    <dt>Version history:

    <dd>Twitter messages (non-editorial changes only): <a
     href="http://twitter.com/WHATWG">http://twitter.com/WHATWG</a>

    <dd>Commit-Watchers mailing list: <a
     href="http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org">http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org</a>

    <dd>Interactive Web interface: <a
     href="http://html5.org/tools/web-workers-tracker">http://html5.org/tools/web-workers-tracker</a>

    <dd>Subversion interface: <a
     href="http://svn.whatwg.org/webworkers/">http://svn.whatwg.org/webworkers/</a>

    <dt>Issues:

    <dd>To send feedback: <a
     href="http://www.whatwg.org/mailing-list">whatwg@whatwg.org</a>

    <dd>To view and vote on feedback: <a
     href="http://www.whatwg.org/issues/">http://www.whatwg.org/issues/</a>

    <dt>Editor:

    <dd>Ian Hickson, Google, ian@hixie.ch
   </dl>

   <p class=copyright>&copy; Copyright 2004-2008 Apple Computer, Inc.,
    Mozilla Foundation, and Opera Software ASA.</p>

   <p class=copyright>You are granted a license to use, reproduce and create
    derivative works of this document.</p>
  </div>

  <hr>

  <h2 class="no-num no-toc" id=abstract>Abstract</h2>

  <p>This specification defines an API that allows Web application authors to
   spawn background workers running scripts in parallel to their main page.
   This allows for thread-like operation with message-passing as the
   coordination mechanism.

  <h2 class="no-num no-toc" id=status>Status of this document</h2>

  <p><strong>This is a work in progress!</strong> This document is changing
   on a daily if not hourly basis in response to comments and as a general
   part of its development process. Comments are very welcome, please send
   them to <a href="mailto:whatwg@whatwg.org">whatwg@whatwg.org</a>. Thank
   you.

  <p>The current focus is in developing a first draft proposal.

  <p>Implementors should be aware that this specification is not stable.
   <strong>Implementors who are not taking part in the discussions are likely
   to find the specification changing out from under them in incompatible
   ways.</strong> Vendors interested in implementing this specification
   before it eventually reaches the call for implementations should join the
   <a href="/mailing-list">WHATWG mailing list</a> and take part in the
   discussions.

  <p>This specification is also being produced by the <a
   href="http://www.w3.org/html/wg">W3C HTML WG</a>. The two specifications
   are identical from the table of contents onwards.

  <h2 class="no-num no-toc" id=contents>Table of contents</h2>
  <!--begin-toc-->

  <ul class=toc>
   <li><a href="#introduction"><span class=secno>1. </span>Introduction</a>
    <ul class=toc>
     <li><a href="#tutorial"><span class=secno>1.1 </span>Tutorial</a>

     <li><a href="#requirements"><span class=secno>1.2
      </span>Requirements</a>

     <li><a href="#conformance"><span class=secno>1.3 </span>Conformance
      requirements</a>
      <ul class=toc>
       <li><a href="#dependencies"><span class=secno>1.3.1
        </span>Dependencies</a>
      </ul>

     <li><a href="#terminology"><span class=secno>1.4 </span>Terminology</a>
    </ul>

   <li><a href="#inside"><span class=secno>2. </span>Inside workers</a>
    <ul class=toc>
     <li><a href="#the-windowworker"><span class=secno>2.1 </span>The
      <code>WindowWorker</code> interface</a>

     <li><a href="#the-queue"><span class=secno>2.2 </span>The queue of
      events</a>

     <li><a href="#processing"><span class=secno>2.3 </span>Processing
      model</a>
    </ul>

   <li><a href="#creating"><span class=secno>3. </span>Creating workers</a>
    <ul class=toc>
     <li><a href="#the-windowworkercreators"><span class=secno>3.1 </span>The
      <code>WindowWorkerCreators</code> interface</a>
    </ul>

   <li class=no-num><a href="#references">References</a>

   <li class=no-num><a href="#acknowledgements">Acknowledgements</a>
  </ul>
  <!--end-toc-->

  <hr>

  <h2 id=introduction><span class=secno>1. </span>Introduction</h2>

  <h3 id=tutorial><span class=secno>1.1 </span>Tutorial</h3>

  <p><em>This section is non-normative.</em>

  <p class=big-issue>This section is missing.

  <h3 id=requirements><span class=secno>1.2 </span>Requirements</h3>

  <p><em>This section is non-normative.</em>

  <p>This specification aims to address the following use cases and
   requirements:

  <ul>
   <li>Background workers: A Web application needs to keep its data
    synchronised with the server, both sending updates to the server and
    receiving updates from the server, including handling buffering of
    updates for when the application goes offline. The code to do this would
    ideally be independent of the UI code.

   <li>URLs: Workers should be spawned from URLs, not from strings, since
    script rarely has access to its own source.

   <li>Message queuing: Messages sent to a worker before the worker has
    initialised should not be lost.

   <li>Workers should have access to timers.

   <li>Workers should have access to the network.

   <li>Workers should be able to use libraries.

   <li>Implementations should not have to expose <code>Node</code> or
    <code>Document</code> objects to workers.

   <li>Workers should not share anything with the outside world. The objects
    representing the worker in the worker itself and in the context that
    created the worker should be different, for instance.

   <li>Shared workers: Multiple instances of the same Web application would
    want to keep just one connection back to the server.

   <li>Capabilities granting: It should be possible for code running in one
    iframe to negotiate a connection to another iframe, with that connection
    granting certain rights (e.g. adding to an address book but not reading
    from it).

   <li>Delegation: It should be possible for one worker to spawn another
    worker and efficiently delagate a request to that worker, without the
    caller being aware of the delagate and without the original worker having
    to proxy all the messages.

   <li>Workers whose parents are not longer useful should be killed. Workers
    should be able to detect this is about to happen and exit gracefully.
  </ul>

  <h3 id=conformance><span class=secno>1.3 </span>Conformance requirements</h3>

  <p>All diagrams, examples, and notes in this specification are
   non-normative, as are all sections explicitly marked non-normative.
   Everything else in this specification is normative.

  <p>The key words "MUST", "MUST NOT", "REQUIRED", <!--"SHALL", "SHALL
  NOT",-->
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the
   normative parts of this document are to be interpreted as described in
   RFC2119. For readability, these words do not appear in all uppercase
   letters in this specification. <a href="#refsRFC2119">[RFC2119]</a></p>
  <!-- XXX but they should be
  marked up -->

  <p>Requirements phrased in the imperative as part of algorithms (such as
   "strip any leading space characters" or "return false and abort these
   steps") are to be interpreted with the meaning of the key word ("must",
   "should", "may", etc) used in introducing the algorithm.

  <p>Some conformance requirements are phrased as requirements on attributes,
   methods or objects. Such requirements are to be interpreted as
   requirements on user agents.

  <p>Conformance requirements phrased as algorithms or specific steps may be
   implemented in any manner, so long as the end result is equivalent. (In
   particular, the algorithms defined in this specification are intended to
   be easy to follow, and not intended to be performant.)

  <p>The only conformance class defined by this specification is user agents.

  <p>User agents may impose implementation-specific limits on otherwise
   unconstrained inputs, e.g. to prevent denial of service attacks, to guard
   against running out of memory, or to work around platform-specific
   limitations.

  <h4 id=dependencies><span class=secno>1.3.1 </span>Dependencies</h4>

  <p>This specification relies on several other underlying specifications.

  <dl>
   <dt>HTML5

   <dd>
    <p>Many fundamental concepts from HTML5 are used by this specification.
     <a href="#refsHTML5">[HTML5]</a></p>

   <dt>ECMAScript

   <dd>
    <p>This specification is intended to be used with JavaScript as the
     scripting language. <a href="#refsJS">[JS]</a></p>

   <dt>WebIDL

   <dd>
    <p>The IDL blocks in this specification use the semantics of the WebIDL
     specification. <a href="#refsWebIDL">[WebIDL]</a></p>
  </dl>

  <h3 id=terminology><span class=secno>1.4 </span>Terminology</h3>

  <p>For simplicity, terms such as <em>shown</em>, <em>displayed</em>, and
   <em>visible</em> might sometimes be used when referring to the way a
   document is rendered to the user. These terms are not meant to imply a
   visual medium; they must be considered to apply to other media in
   equivalent ways.

  <p>The construction "a <code title="">Foo</code> object", where <code
   title="">Foo</code> is actually an interface, is sometimes used instead of
   the more accurate "an object implementing the interface <code
   title="">Foo</code>".

  <p>The term DOM is used to refer to the API set made available to scripts
   in Web applications, and does not necessarily imply the existence of an
   actual <code>Document</code> object or of any other <code>Node</code>
   objects as defined in the DOM Core specifications. <a
   href="#refsDOM3CORE">[DOM3CORE]</a>

  <p>A DOM attribute is said to be <em>getting</em> when its value is being
   retrieved (e.g. by author script), and is said to be <em>setting</em> when
   a new value is assigned to it.

  <p>If a DOM object is said to be <dfn id=live>live</dfn>, then that means
   that any attributes returning that object must always return the same
   object (not a new object each time), and the attributes and methods on
   that object must operate on the actual underlying data, not a snapshot of
   the data.

  <h2 id=inside><span class=secno>2. </span>Inside workers</h2>

  <h3 id=the-windowworker><span class=secno>2.1 </span>The <code><a
   href="#windowworker">WindowWorker</a></code> interface</h3>

  <pre
   class=idl>[NoInterfaceObject] interface <dfn id=windowworker>WindowWorker</dfn> {
  readonly attribute boolean <a href="#name" title=dom-windowworker-name>name</a>;
  readonly attribute boolean <a href="#closing" title=dom-windowworker-closing>closing</a>;
};</pre>

  <p>Objects that implement the <code><a
   href="#windowworker">WindowWorker</a></code> interface must also implement
   the <code>Window</code> interface (and thus also the
   <code>WindowTimers</code> and <code><a
   href="#windowworkercreators">WindowWorkerCreators</a></code> interfaces)
   and the <code>EventTarget</code> interface.

  <p>The <dfn id=name title=dom-windowworker-name><code>name</code></dfn>
   attribute must return the value it was assigned when the <code><a
   href="#windowworker">WindowWorker</a></code> object was created by the "<a
   href="#run-a">run a worker</a>" algorithm.

  <p>The <dfn id=closing
   title=dom-windowworker-closing><code>closing</code></dfn> attribute must
   return false until the "<a href="#kill-a">kill a worker</a>" processing
   model defined below sets it to false.

  <h3 id=the-queue><span class=secno>2.2 </span>The queue of events</h3>

  <p>Each <code><a href="#windowworker">WindowWorker</a></code> object is
   asssociated with a <dfn id=queue>queue of events</dfn>, which is initially
   empty.

  <p>An event in the queue can be a DOM event or a timeout callback.

  <h3 id=processing><span class=secno>2.3 </span>Processing model</h3>

  <p>When a user agent is to <dfn id=run-a>run a worker</dfn> named <var
   title="">name</var> for a script <var title="">script</var>, a browsing
   context <var title="">owner browsing context</var> and a
   <code>Document</code> <var title="">owner document</var>, it must run the
   following steps in a completely separate and parallel execution
   environment:

  <ol>
   <li>
    <p>Create a new <code><a href="#windowworker">WindowWorker</a></code>
     object, <var title="">window</var>.</p>

   <li>
    <p>Set the <code title=dom-windowworker-name><a
     href="#name">name</a></code> attribute of <var title="">window</var> to
     the value of <var title="">name</var>.</p>

   <li>
    <p>Let <var title="">script</var>'s <span>script execution context</span>
     (and thus also <span>global object</span>) be <var
     title="">window</var>.</p>

   <li>
    <p>Let <var title="">script</var>'s <span>script browsing context</span>
     be <var title="">owner browsing context</var>.</p>

   <li>
    <p>Let <var title="">script</var>'s <span>script document context</span>
     be <var title="">owner document</var>.</p>

   <li>
    <p>Run <var title="">script</var> until it returns.</p>

   <li>
    <p><i>Event loop</i>: Wait until there is an event in the <a
     href="#queue">queue of events</a> associated with <var
     title="">window</var>.</p>

   <li>
    <p>Dispatch the oldest event or callback in the <a href="#queue">queue of
     events</a>. Events must be targetted at the <code><a
     href="#windowworker">WindowWorker</a></code> object.</p>

   <li>
    <p>If there are any more events in the <a href="#queue">queue of
     events</a> or if the <var title="">window</var> object's <code
     title=dom-windowworker-closing><a href="#closing">closing</a></code>
     attribute is set to false, then jump back to the step above labeled
     <i>event loop</i>.</p>

   <li>
    <p class=big-issue>timers, intervals, XMLHttpRequests, database
     transactions, etc, must be killed; ports must be deactivated and
     unentangled</p>
  </ol>

  <hr>

  <p>When a user agent is to <dfn id=kill-a>kill a worker</dfn>, it must run
   the following steps in parallel with the worker's main loop (the "<a
   href="#run-a">run a worker</a>" processing model defined above):

  <ol>
   <li>
    <p>Set the worker's <code><a href="#windowworker">WindowWorker</a></code>
     object's <code title=dom-windowworker-closing><a
     href="#closing">closing</a></code> attribute to true.

   <li>
    <p>Create an <code>Event</code> object with the event name <code
     title=event-unload>unload</code>, which does not bubble and is not
     cancelable, and add it to the worker's <code><a
     href="#windowworker">WindowWorker</a></code> object's <a
     href="#queue">queue of events</a>.

   <li>
    <p>Wait a user-agent-defined amount of time.

   <li>
    <p>If there are any events in the <a href="#queue">queue of events</a>
     other than the <code title=event-unload>unload</code> event that this
     algorithm just added, discard them without dispatching them.

   <li>
    <p>If the <code title=event-unload>unload</code> event that this
     algorithm just added hasn't yet been dispatched, then abort the script
     currently running in the worker.

   <li>
    <p>Wait a user-agent-defined amount of time.

   <li>
    <p>Abort the script currently running in the worker (if any script is
     running, then it will be a handler for the <code
     title=event-unload>unload</code> event).
  </ol>

  <h2 id=creating><span class=secno>3. </span>Creating workers</h2>

  <h3 id=the-windowworkercreators><span class=secno>3.1 </span>The <code><a
   href="#windowworkercreators">WindowWorkerCreators</a></code> interface</h3>

  <pre
   class=idl>[NoInterfaceObject] interface <dfn id=windowworkercreators>WindowWorkerCreators</dfn> {
  <span>MessagePort</span> <span title=dom-WindowWorkerCreators-createWorker>createWorker</span>(in DOMString scriptURI);
  <span>MessagePort</span> <span title=dom-WindowWorkerCreators-createNamedWorker>createNamedWorker</span>(in DOMString name, in DOMString scriptURI);
};</pre>

  <p>Objects that implement the <code>Window</code> interface must also
   implement the <code><a
   href="#windowworkercreators">WindowWorkerCreators</a></code> interface.

  <p class=big-issue>...

  <h2 class=no-num id=references>References</h2>

  <p class=big-issue>This section will be written in a future
   draft.<!--XXX-->

  <h2 class=no-num id=acknowledgements>Acknowledgements</h2>
  <!-- ACKS -->

  <p>Thanks to Maciej Stachowiak and Mike Smith for their useful and
   substantial comments.

  <p>Huge thanks to the whole Gears team, who pioneered this technology and
   whose experience has been a huge influence on this specification.
1	wakaba	1.1
2			<html lang=en-US-x-hixie>
3			<head>
4			<title>Web Workers</title>
5			<link href="/style/specification" rel=stylesheet>
6			<link href="/images/icon" rel=icon>
7
8			<body class=draft>
9			<div class=head>
10			<p><a class=logo href="http://www.whatwg.org/" rel=home><img alt=WHATWG
11			src="/images/logo"></a></p>
12
13			<h1 id=web-workers>Web Workers</h1>
14
15	wakaba	1.3	<h2 class="no-num no-toc" id=draft>Draft Recommendation — 16 July
16	wakaba	1.1	2008</h2>
17
18			<p>You can take part in this work. <a
19			href="http://www.whatwg.org/mailing-list">Join the working group's
20			discussion list.</a></p>
21
22			<p><strong>Web designers!</strong> We have a <a
23			href="http://blog.whatwg.org/faq/">FAQ</a>, a <a
24			href="http://forums.whatwg.org/">forum</a>, and a <a
25			href="http://www.whatwg.org/mailing-list#help">help mailing list</a> for
26			you!</p>
27
28			<dl>
29			<dt>This version:
30
31			<dd><a
32			href="http://www.whatwg.org/specs/web-workers/current-work/">http://www.whatwg.org/specs/web-workers/current-work/</a>
33
34			<dt>Version history:
35
36			<dd>Twitter messages (non-editorial changes only): <a
37			href="http://twitter.com/WHATWG">http://twitter.com/WHATWG</a>
38
39			<dd>Commit-Watchers mailing list: <a
40			href="http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org">http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org</a>
41
42			<dd>Interactive Web interface: <a
43			href="http://html5.org/tools/web-workers-tracker">http://html5.org/tools/web-workers-tracker</a>
44
45			<dd>Subversion interface: <a
46			href="http://svn.whatwg.org/webworkers/">http://svn.whatwg.org/webworkers/</a>
47
48			<dt>Issues:
49
50			<dd>To send feedback: <a
51			href="http://www.whatwg.org/mailing-list">whatwg@whatwg.org</a>
52
53			<dd>To view and vote on feedback: <a
54			href="http://www.whatwg.org/issues/">http://www.whatwg.org/issues/</a>
55
56			<dt>Editor:
57
58			<dd>Ian Hickson, Google, ian@hixie.ch
59			</dl>
60
61			<p class=copyright>© Copyright 2004-2008 Apple Computer, Inc.,
62			Mozilla Foundation, and Opera Software ASA.</p>
63
64			<p class=copyright>You are granted a license to use, reproduce and create
65			derivative works of this document.</p>
66			</div>
67
68			<hr>
69
70			<h2 class="no-num no-toc" id=abstract>Abstract</h2>
71
72			<p>This specification defines an API that allows Web application authors to
73			spawn background workers running scripts in parallel to their main page.
74			This allows for thread-like operation with message-passing as the
75			coordination mechanism.
76
77			<h2 class="no-num no-toc" id=status>Status of this document</h2>
78
79			<p><strong>This is a work in progress!</strong> This document is changing
80			on a daily if not hourly basis in response to comments and as a general
81			part of its development process. Comments are very welcome, please send
82			them to <a href="mailto:whatwg@whatwg.org">whatwg@whatwg.org</a>. Thank
83			you.
84
85			<p>The current focus is in developing a first draft proposal.
86
87			<p>Implementors should be aware that this specification is not stable.
88			<strong>Implementors who are not taking part in the discussions are likely
89			to find the specification changing out from under them in incompatible
90			ways.</strong> Vendors interested in implementing this specification
91			before it eventually reaches the call for implementations should join the
92			<a href="/mailing-list">WHATWG mailing list</a> and take part in the
93			discussions.
94
95			<p>This specification is also being produced by the <a
96			href="http://www.w3.org/html/wg">W3C HTML WG</a>. The two specifications
97			are identical from the table of contents onwards.
98
99			<h2 class="no-num no-toc" id=contents>Table of contents</h2>
100			<!--begin-toc-->
101
102			<ul class=toc>
103			<li><a href="#introduction"><span class=secno>1. </span>Introduction</a>
104			<ul class=toc>
105	wakaba	1.3	<li><a href="#tutorial"><span class=secno>1.1 </span>Tutorial</a>
106	wakaba	1.1
107	wakaba	1.2	<li><a href="#requirements"><span class=secno>1.2
108			</span>Requirements</a>
109	wakaba	1.1
110	wakaba	1.3	<li><a href="#conformance"><span class=secno>1.3 </span>Conformance
111	wakaba	1.1	requirements</a>
112			<ul class=toc>
113	wakaba	1.3	<li><a href="#dependencies"><span class=secno>1.3.1
114	wakaba	1.1	</span>Dependencies</a>
115			</ul>
116
117	wakaba	1.3	<li><a href="#terminology"><span class=secno>1.4 </span>Terminology</a>
118			</ul>
119
120			<li><a href="#inside"><span class=secno>2. </span>Inside workers</a>
121			<ul class=toc>
122			<li><a href="#the-windowworker"><span class=secno>2.1 </span>The
123			<code>WindowWorker</code> interface</a>
124
125			<li><a href="#the-queue"><span class=secno>2.2 </span>The queue of
126			events</a>
127
128			<li><a href="#processing"><span class=secno>2.3 </span>Processing
129			model</a>
130			</ul>
131
132			<li><a href="#creating"><span class=secno>3. </span>Creating workers</a>
133			<ul class=toc>
134			<li><a href="#the-windowworkercreators"><span class=secno>3.1 </span>The
135			<code>WindowWorkerCreators</code> interface</a>
136	wakaba	1.1	</ul>
137
138			<li class=no-num><a href="#references">References</a>
139
140			<li class=no-num><a href="#acknowledgements">Acknowledgements</a>
141			</ul>
142			<!--end-toc-->
143
144			<hr>
145
146			<h2 id=introduction><span class=secno>1. </span>Introduction</h2>
147
148	wakaba	1.3	<h3 id=tutorial><span class=secno>1.1 </span>Tutorial</h3>
149	wakaba	1.1
150			<p><em>This section is non-normative.</em>
151
152	wakaba	1.3	<p class=big-issue>This section is missing.
153
154	wakaba	1.2	<h3 id=requirements><span class=secno>1.2 </span>Requirements</h3>
155	wakaba	1.1
156			<p><em>This section is non-normative.</em>
157	wakaba	1.2
158			<p>This specification aims to address the following use cases and
159			requirements:
160
161			<ul>
162			<li>Background workers: A Web application needs to keep its data
163			synchronised with the server, both sending updates to the server and
164			receiving updates from the server, including handling buffering of
165			updates for when the application goes offline. The code to do this would
166			ideally be independent of the UI code.
167
168			<li>URLs: Workers should be spawned from URLs, not from strings, since
169			script rarely has access to its own source.
170
171			<li>Message queuing: Messages sent to a worker before the worker has
172			initialised should not be lost.
173
174			<li>Workers should have access to timers.
175
176			<li>Workers should have access to the network.
177
178			<li>Workers should be able to use libraries.
179
180			<li>Implementations should not have to expose <code>Node</code> or
181			<code>Document</code> objects to workers.
182
183			<li>Workers should not share anything with the outside world. The objects
184			representing the worker in the worker itself and in the context that
185			created the worker should be different, for instance.
186
187			<li>Shared workers: Multiple instances of the same Web application would
188			want to keep just one connection back to the server.
189
190			<li>Capabilities granting: It should be possible for code running in one
191			iframe to negotiate a connection to another iframe, with that connection
192			granting certain rights (e.g. adding to an address book but not reading
193			from it).
194
195			<li>Delegation: It should be possible for one worker to spawn another
196			worker and efficiently delagate a request to that worker, without the
197			caller being aware of the delagate and without the original worker having
198			to proxy all the messages.
199
200			<li>Workers whose parents are not longer useful should be killed. Workers
201			should be able to detect this is about to happen and exit gracefully.
202			</ul>
203	wakaba	1.1
204	wakaba	1.3	<h3 id=conformance><span class=secno>1.3 </span>Conformance requirements</h3>
205	wakaba	1.1
206			<p>All diagrams, examples, and notes in this specification are
207			non-normative, as are all sections explicitly marked non-normative.
208			Everything else in this specification is normative.
209
210			<p>The key words "MUST", "MUST NOT", "REQUIRED", <!--"SHALL", "SHALL
211			NOT",-->
212			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the
213			normative parts of this document are to be interpreted as described in
214			RFC2119. For readability, these words do not appear in all uppercase
215			letters in this specification. <a href="#refsRFC2119">[RFC2119]</a></p>
216			<!-- XXX but they should be
217			marked up -->
218
219			<p>Requirements phrased in the imperative as part of algorithms (such as
220			"strip any leading space characters" or "return false and abort these
221			steps") are to be interpreted with the meaning of the key word ("must",
222			"should", "may", etc) used in introducing the algorithm.
223
224			<p>Some conformance requirements are phrased as requirements on attributes,
225			methods or objects. Such requirements are to be interpreted as
226			requirements on user agents.
227
228			<p>Conformance requirements phrased as algorithms or specific steps may be
229			implemented in any manner, so long as the end result is equivalent. (In
230			particular, the algorithms defined in this specification are intended to
231			be easy to follow, and not intended to be performant.)
232
233			<p>The only conformance class defined by this specification is user agents.
234
235			<p>User agents may impose implementation-specific limits on otherwise
236			unconstrained inputs, e.g. to prevent denial of service attacks, to guard
237			against running out of memory, or to work around platform-specific
238			limitations.
239
240	wakaba	1.3	<h4 id=dependencies><span class=secno>1.3.1 </span>Dependencies</h4>
241	wakaba	1.1
242			<p>This specification relies on several other underlying specifications.
243
244			<dl>
245			<dt>HTML5
246
247			<dd>
248			<p>Many fundamental concepts from HTML5 are used by this specification.
249			<a href="#refsHTML5">[HTML5]</a></p>
250
251			<dt>ECMAScript
252
253			<dd>
254			<p>This specification is intended to be used with JavaScript as the
255			scripting language. <a href="#refsJS">[JS]</a></p>
256
257			<dt>WebIDL
258
259			<dd>
260			<p>The IDL blocks in this specification use the semantics of the WebIDL
261			specification. <a href="#refsWebIDL">[WebIDL]</a></p>
262			</dl>
263
264	wakaba	1.3	<h3 id=terminology><span class=secno>1.4 </span>Terminology</h3>
265	wakaba	1.1
266			<p>For simplicity, terms such as <em>shown</em>, <em>displayed</em>, and
267			<em>visible</em> might sometimes be used when referring to the way a
268			document is rendered to the user. These terms are not meant to imply a
269			visual medium; they must be considered to apply to other media in
270			equivalent ways.
271
272	wakaba	1.3	<p>The construction "a <code title="">Foo</code> object", where <code
273			title="">Foo</code> is actually an interface, is sometimes used instead of
274			the more accurate "an object implementing the interface <code
275			title="">Foo</code>".
276	wakaba	1.1
277			<p>The term DOM is used to refer to the API set made available to scripts
278			in Web applications, and does not necessarily imply the existence of an
279			actual <code>Document</code> object or of any other <code>Node</code>
280			objects as defined in the DOM Core specifications. <a
281			href="#refsDOM3CORE">[DOM3CORE]</a>
282
283			<p>A DOM attribute is said to be <em>getting</em> when its value is being
284			retrieved (e.g. by author script), and is said to be <em>setting</em> when
285			a new value is assigned to it.
286
287			<p>If a DOM object is said to be <dfn id=live>live</dfn>, then that means
288			that any attributes returning that object must always return the same
289			object (not a new object each time), and the attributes and methods on
290			that object must operate on the actual underlying data, not a snapshot of
291			the data.
292
293	wakaba	1.3	<h2 id=inside><span class=secno>2. </span>Inside workers</h2>
294
295			<h3 id=the-windowworker><span class=secno>2.1 </span>The <code><a
296			href="#windowworker">WindowWorker</a></code> interface</h3>
297
298			<pre
299			class=idl>[NoInterfaceObject] interface <dfn id=windowworker>WindowWorker</dfn> {
300			readonly attribute boolean <a href="#name" title=dom-windowworker-name>name</a>;
301			readonly attribute boolean <a href="#closing" title=dom-windowworker-closing>closing</a>;
302			};</pre>
303
304			<p>Objects that implement the <code><a
305			href="#windowworker">WindowWorker</a></code> interface must also implement
306			the <code>Window</code> interface (and thus also the
307			<code>WindowTimers</code> and <code><a
308			href="#windowworkercreators">WindowWorkerCreators</a></code> interfaces)
309			and the <code>EventTarget</code> interface.
310
311			<p>The <dfn id=name title=dom-windowworker-name><code>name</code></dfn>
312			attribute must return the value it was assigned when the <code><a
313			href="#windowworker">WindowWorker</a></code> object was created by the "<a
314			href="#run-a">run a worker</a>" algorithm.
315
316			<p>The <dfn id=closing
317			title=dom-windowworker-closing><code>closing</code></dfn> attribute must
318			return false until the "<a href="#kill-a">kill a worker</a>" processing
319			model defined below sets it to false.
320
321			<h3 id=the-queue><span class=secno>2.2 </span>The queue of events</h3>
322
323			<p>Each <code><a href="#windowworker">WindowWorker</a></code> object is
324			asssociated with a <dfn id=queue>queue of events</dfn>, which is initially
325			empty.
326
327			<p>An event in the queue can be a DOM event or a timeout callback.
328
329			<h3 id=processing><span class=secno>2.3 </span>Processing model</h3>
330
331			<p>When a user agent is to <dfn id=run-a>run a worker</dfn> named <var
332			title="">name</var> for a script <var title="">script</var>, a browsing
333			context <var title="">owner browsing context</var> and a
334			<code>Document</code> <var title="">owner document</var>, it must run the
335			following steps in a completely separate and parallel execution
336			environment:
337
338			<ol>
339			<li>
340			<p>Create a new <code><a href="#windowworker">WindowWorker</a></code>
341			object, <var title="">window</var>.</p>
342
343			<li>
344			<p>Set the <code title=dom-windowworker-name><a
345			href="#name">name</a></code> attribute of <var title="">window</var> to
346			the value of <var title="">name</var>.</p>
347
348			<li>
349			<p>Let <var title="">script</var>'s <span>script execution context</span>
350			(and thus also <span>global object</span>) be <var
351			title="">window</var>.</p>
352
353			<li>
354			<p>Let <var title="">script</var>'s <span>script browsing context</span>
355			be <var title="">owner browsing context</var>.</p>
356
357			<li>
358			<p>Let <var title="">script</var>'s <span>script document context</span>
359			be <var title="">owner document</var>.</p>
360
361			<li>
362			<p>Run <var title="">script</var> until it returns.</p>
363
364			<li>
365			<p><i>Event loop</i>: Wait until there is an event in the <a
366			href="#queue">queue of events</a> associated with <var
367			title="">window</var>.</p>
368
369			<li>
370			<p>Dispatch the oldest event or callback in the <a href="#queue">queue of
371			events</a>. Events must be targetted at the <code><a
372			href="#windowworker">WindowWorker</a></code> object.</p>
373
374			<li>
375			<p>If there are any more events in the <a href="#queue">queue of
376			events</a> or if the <var title="">window</var> object's <code
377			title=dom-windowworker-closing><a href="#closing">closing</a></code>
378			attribute is set to false, then jump back to the step above labeled
379			<i>event loop</i>.</p>
380
381			<li>
382			<p class=big-issue>timers, intervals, XMLHttpRequests, database
383			transactions, etc, must be killed; ports must be deactivated and
384			unentangled</p>
385			</ol>
386
387			<hr>
388
389			<p>When a user agent is to <dfn id=kill-a>kill a worker</dfn>, it must run
390			the following steps in parallel with the worker's main loop (the "<a
391			href="#run-a">run a worker</a>" processing model defined above):
392
393			<ol>
394			<li>
395			<p>Set the worker's <code><a href="#windowworker">WindowWorker</a></code>
396			object's <code title=dom-windowworker-closing><a
397			href="#closing">closing</a></code> attribute to true.
398
399			<li>
400			<p>Create an <code>Event</code> object with the event name <code
401			title=event-unload>unload</code>, which does not bubble and is not
402			cancelable, and add it to the worker's <code><a
403			href="#windowworker">WindowWorker</a></code> object's <a
404			href="#queue">queue of events</a>.
405
406			<li>
407			<p>Wait a user-agent-defined amount of time.
408
409			<li>
410			<p>If there are any events in the <a href="#queue">queue of events</a>
411			other than the <code title=event-unload>unload</code> event that this
412			algorithm just added, discard them without dispatching them.
413
414			<li>
415			<p>If the <code title=event-unload>unload</code> event that this
416			algorithm just added hasn't yet been dispatched, then abort the script
417			currently running in the worker.
418
419			<li>
420			<p>Wait a user-agent-defined amount of time.
421
422			<li>
423			<p>Abort the script currently running in the worker (if any script is
424			running, then it will be a handler for the <code
425			title=event-unload>unload</code> event).
426			</ol>
427
428			<h2 id=creating><span class=secno>3. </span>Creating workers</h2>
429
430			<h3 id=the-windowworkercreators><span class=secno>3.1 </span>The <code><a
431			href="#windowworkercreators">WindowWorkerCreators</a></code> interface</h3>
432
433			<pre
434			class=idl>[NoInterfaceObject] interface <dfn id=windowworkercreators>WindowWorkerCreators</dfn> {
435			<span>MessagePort</span> <span title=dom-WindowWorkerCreators-createWorker>createWorker</span>(in DOMString scriptURI);
436			<span>MessagePort</span> <span title=dom-WindowWorkerCreators-createNamedWorker>createNamedWorker</span>(in DOMString name, in DOMString scriptURI);
437			};</pre>
438
439			<p>Objects that implement the <code>Window</code> interface must also
440			implement the <code><a
441			href="#windowworkercreators">WindowWorkerCreators</a></code> interface.
442
443			<p class=big-issue>...
444
445	wakaba	1.1	<h2 class=no-num id=references>References</h2>
446
447			<p class=big-issue>This section will be written in a future
448			draft.<!--XXX-->
449
450			<h2 class=no-num id=acknowledgements>Acknowledgements</h2>
451			<!-- ACKS -->
452
453			<p>Thanks to Maciej Stachowiak and Mike Smith for their useful and
454			substantial comments.
455	wakaba	1.3
456			<p>Huge thanks to the whole Gears team, who pioneered this technology and
457			whose experience has been a huge influence on this specification.