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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">

<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; 10 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">[email protected]</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, [email protected]
   </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:[email protected]">[email protected]</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="#background"><span class=secno>1.1 </span>Background</a>

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

     <li><a href="#relationships"><span class=secno>1.3 </span>Relationships
      to other specifications</a>
      <ul class=toc>
       <li><a href="#relationship"><span class=secno>1.3.1
        </span>Relationship to HTML5</a>

       <li><a href="#relationship0"><span class=secno>1.3.2
        </span>Relationship to ECMAScript</a>
      </ul>

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

     <li><a href="#terminology"><span class=secno>1.5 </span>Terminology</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=background><span class=secno>1.1 </span>Background</h3>

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

  <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=relationships><span class=secno>1.3 </span>Relationships to other
   specifications</h3>

  <h4 id=relationship><span class=secno>1.3.1 </span>Relationship to HTML5</h4>

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

  <h4 id=relationship0><span class=secno>1.3.2 </span>Relationship to
   ECMAScript</h4>

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

  <h3 id=conformance><span class=secno>1.4 </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.4.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.5 </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>Foo</code> object", where <code>Foo</code> is
   actually an interface, is sometimes used instead of the more accurate "an
   object implementing the interface <code>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 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.
1	wakaba	1.1	<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
2
3			<html lang=en-US-x-hixie>
4			<head>
5			<title>Web Workers</title>
6			<link href="/style/specification" rel=stylesheet>
7			<link href="/images/icon" rel=icon>
8
9			<body class=draft>
10			<div class=head>
11			<p><a class=logo href="http://www.whatwg.org/" rel=home><img alt=WHATWG
12			src="/images/logo"></a></p>
13
14			<h1 id=web-workers>Web Workers</h1>
15
16	wakaba	1.2	<h2 class="no-num no-toc" id=draft>Draft Recommendation — 10 July
17	wakaba	1.1	2008</h2>
18
19			<p>You can take part in this work. <a
20			href="http://www.whatwg.org/mailing-list">Join the working group's
21			discussion list.</a></p>
22
23			<p><strong>Web designers!</strong> We have a <a
24			href="http://blog.whatwg.org/faq/">FAQ</a>, a <a
25			href="http://forums.whatwg.org/">forum</a>, and a <a
26			href="http://www.whatwg.org/mailing-list#help">help mailing list</a> for
27			you!</p>
28
29			<dl>
30			<dt>This version:
31
32			<dd><a
33			href="http://www.whatwg.org/specs/web-workers/current-work/">http://www.whatwg.org/specs/web-workers/current-work/</a>
34
35			<dt>Version history:
36
37			<dd>Twitter messages (non-editorial changes only): <a
38			href="http://twitter.com/WHATWG">http://twitter.com/WHATWG</a>
39
40			<dd>Commit-Watchers mailing list: <a
41			href="http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org">http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org</a>
42
43			<dd>Interactive Web interface: <a
44			href="http://html5.org/tools/web-workers-tracker">http://html5.org/tools/web-workers-tracker</a>
45
46			<dd>Subversion interface: <a
47			href="http://svn.whatwg.org/webworkers/">http://svn.whatwg.org/webworkers/</a>
48
49			<dt>Issues:
50
51			<dd>To send feedback: <a
52			href="http://www.whatwg.org/mailing-list">[email protected]</a>
53
54			<dd>To view and vote on feedback: <a
55			href="http://www.whatwg.org/issues/">http://www.whatwg.org/issues/</a>
56
57			<dt>Editor:
58
59			<dd>Ian Hickson, Google, [email protected]
60			</dl>
61
62			<p class=copyright>© Copyright 2004-2008 Apple Computer, Inc.,
63			Mozilla Foundation, and Opera Software ASA.</p>
64
65			<p class=copyright>You are granted a license to use, reproduce and create
66			derivative works of this document.</p>
67			</div>
68
69			<hr>
70
71			<h2 class="no-num no-toc" id=abstract>Abstract</h2>
72
73			<p>This specification defines an API that allows Web application authors to
74			spawn background workers running scripts in parallel to their main page.
75			This allows for thread-like operation with message-passing as the
76			coordination mechanism.
77
78			<h2 class="no-num no-toc" id=status>Status of this document</h2>
79
80			<p><strong>This is a work in progress!</strong> This document is changing
81			on a daily if not hourly basis in response to comments and as a general
82			part of its development process. Comments are very welcome, please send
83			them to <a href="mailto:[email protected]">[email protected]</a>. Thank
84			you.
85
86			<p>The current focus is in developing a first draft proposal.
87
88			<p>Implementors should be aware that this specification is not stable.
89			<strong>Implementors who are not taking part in the discussions are likely
90			to find the specification changing out from under them in incompatible
91			ways.</strong> Vendors interested in implementing this specification
92			before it eventually reaches the call for implementations should join the
93			<a href="/mailing-list">WHATWG mailing list</a> and take part in the
94			discussions.
95
96			<p>This specification is also being produced by the <a
97			href="http://www.w3.org/html/wg">W3C HTML WG</a>. The two specifications
98			are identical from the table of contents onwards.
99
100			<h2 class="no-num no-toc" id=contents>Table of contents</h2>
101			<!--begin-toc-->
102
103			<ul class=toc>
104			<li><a href="#introduction"><span class=secno>1. </span>Introduction</a>
105			<ul class=toc>
106			<li><a href="#background"><span class=secno>1.1 </span>Background</a>
107
108	wakaba	1.2	<li><a href="#requirements"><span class=secno>1.2
109			</span>Requirements</a>
110	wakaba	1.1
111			<li><a href="#relationships"><span class=secno>1.3 </span>Relationships
112			to other specifications</a>
113			<ul class=toc>
114			<li><a href="#relationship"><span class=secno>1.3.1
115			</span>Relationship to HTML5</a>
116
117			<li><a href="#relationship0"><span class=secno>1.3.2
118			</span>Relationship to ECMAScript</a>
119			</ul>
120
121			<li><a href="#conformance"><span class=secno>1.4 </span>Conformance
122			requirements</a>
123			<ul class=toc>
124			<li><a href="#dependencies"><span class=secno>1.4.1
125			</span>Dependencies</a>
126			</ul>
127
128			<li><a href="#terminology"><span class=secno>1.5 </span>Terminology</a>
129			</ul>
130
131			<li class=no-num><a href="#references">References</a>
132
133			<li class=no-num><a href="#acknowledgements">Acknowledgements</a>
134			</ul>
135			<!--end-toc-->
136
137			<hr>
138
139			<h2 id=introduction><span class=secno>1. </span>Introduction</h2>
140
141			<h3 id=background><span class=secno>1.1 </span>Background</h3>
142
143			<p><em>This section is non-normative.</em>
144
145	wakaba	1.2	<h3 id=requirements><span class=secno>1.2 </span>Requirements</h3>
146	wakaba	1.1
147			<p><em>This section is non-normative.</em>
148	wakaba	1.2
149			<p>This specification aims to address the following use cases and
150			requirements:
151
152			<ul>
153			<li>Background workers: A Web application needs to keep its data
154			synchronised with the server, both sending updates to the server and
155			receiving updates from the server, including handling buffering of
156			updates for when the application goes offline. The code to do this would
157			ideally be independent of the UI code.
158
159			<li>URLs: Workers should be spawned from URLs, not from strings, since
160			script rarely has access to its own source.
161
162			<li>Message queuing: Messages sent to a worker before the worker has
163			initialised should not be lost.
164
165			<li>Workers should have access to timers.
166
167			<li>Workers should have access to the network.
168
169			<li>Workers should be able to use libraries.
170
171			<li>Implementations should not have to expose <code>Node</code> or
172			<code>Document</code> objects to workers.
173
174			<li>Workers should not share anything with the outside world. The objects
175			representing the worker in the worker itself and in the context that
176			created the worker should be different, for instance.
177
178			<li>Shared workers: Multiple instances of the same Web application would
179			want to keep just one connection back to the server.
180
181			<li>Capabilities granting: It should be possible for code running in one
182			iframe to negotiate a connection to another iframe, with that connection
183			granting certain rights (e.g. adding to an address book but not reading
184			from it).
185
186			<li>Delegation: It should be possible for one worker to spawn another
187			worker and efficiently delagate a request to that worker, without the
188			caller being aware of the delagate and without the original worker having
189			to proxy all the messages.
190
191			<li>Workers whose parents are not longer useful should be killed. Workers
192			should be able to detect this is about to happen and exit gracefully.
193			</ul>
194	wakaba	1.1
195			<h3 id=relationships><span class=secno>1.3 </span>Relationships to other
196			specifications</h3>
197
198			<h4 id=relationship><span class=secno>1.3.1 </span>Relationship to HTML5</h4>
199
200			<p><em>This section is non-normative.</em>
201
202			<h4 id=relationship0><span class=secno>1.3.2 </span>Relationship to
203			ECMAScript</h4>
204
205			<p><em>This section is non-normative.</em>
206
207			<h3 id=conformance><span class=secno>1.4 </span>Conformance requirements</h3>
208
209			<p>All diagrams, examples, and notes in this specification are
210			non-normative, as are all sections explicitly marked non-normative.
211			Everything else in this specification is normative.
212
213			<p>The key words "MUST", "MUST NOT", "REQUIRED", <!--"SHALL", "SHALL
214			NOT",-->
215			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the
216			normative parts of this document are to be interpreted as described in
217			RFC2119. For readability, these words do not appear in all uppercase
218			letters in this specification. <a href="#refsRFC2119">[RFC2119]</a></p>
219			<!-- XXX but they should be
220			marked up -->
221
222			<p>Requirements phrased in the imperative as part of algorithms (such as
223			"strip any leading space characters" or "return false and abort these
224			steps") are to be interpreted with the meaning of the key word ("must",
225			"should", "may", etc) used in introducing the algorithm.
226
227			<p>Some conformance requirements are phrased as requirements on attributes,
228			methods or objects. Such requirements are to be interpreted as
229			requirements on user agents.
230
231			<p>Conformance requirements phrased as algorithms or specific steps may be
232			implemented in any manner, so long as the end result is equivalent. (In
233			particular, the algorithms defined in this specification are intended to
234			be easy to follow, and not intended to be performant.)
235
236			<p>The only conformance class defined by this specification is user agents.
237
238			<p>User agents may impose implementation-specific limits on otherwise
239			unconstrained inputs, e.g. to prevent denial of service attacks, to guard
240			against running out of memory, or to work around platform-specific
241			limitations.
242
243			<h4 id=dependencies><span class=secno>1.4.1 </span>Dependencies</h4>
244
245			<p>This specification relies on several other underlying specifications.
246
247			<dl>
248			<dt>HTML5
249
250			<dd>
251			<p>Many fundamental concepts from HTML5 are used by this specification.
252			<a href="#refsHTML5">[HTML5]</a></p>
253
254			<dt>ECMAScript
255
256			<dd>
257			<p>This specification is intended to be used with JavaScript as the
258			scripting language. <a href="#refsJS">[JS]</a></p>
259
260			<dt>WebIDL
261
262			<dd>
263			<p>The IDL blocks in this specification use the semantics of the WebIDL
264			specification. <a href="#refsWebIDL">[WebIDL]</a></p>
265			</dl>
266
267			<h3 id=terminology><span class=secno>1.5 </span>Terminology</h3>
268
269			<p>For simplicity, terms such as <em>shown</em>, <em>displayed</em>, and
270			<em>visible</em> might sometimes be used when referring to the way a
271			document is rendered to the user. These terms are not meant to imply a
272			visual medium; they must be considered to apply to other media in
273			equivalent ways.
274
275			<p>The construction "a <code>Foo</code> object", where <code>Foo</code> is
276			actually an interface, is sometimes used instead of the more accurate "an
277			object implementing the interface <code>Foo</code>".
278
279			<p>The term DOM is used to refer to the API set made available to scripts
280			in Web applications, and does not necessarily imply the existence of an
281			actual <code>Document</code> object or of any other <code>Node</code>
282			objects as defined in the DOM Core specifications. <a
283			href="#refsDOM3CORE">[DOM3CORE]</a>
284
285			<p>A DOM attribute is said to be <em>getting</em> when its value is being
286			retrieved (e.g. by author script), and is said to be <em>setting</em> when
287			a new value is assigned to it.
288
289			<p>If a DOM object is said to be <dfn id=live>live</dfn>, then that means
290			that any attributes returning that object must always return the same
291			object (not a new object each time), and the attributes and methods on
292			that object must operate on the actual underlying data, not a snapshot of
293			the data.
294
295			<h2 class=no-num id=references>References</h2>
296
297			<p class=big-issue>This section will be written in a future
298			draft.<!--XXX-->
299
300			<h2 class=no-num id=acknowledgements>Acknowledgements</h2>
301			<!-- ACKS -->
302
303			<p>Thanks to Maciej Stachowiak and Mike Smith for their useful and
304			substantial comments.