workers/Overview.html 1.22 29 Remove requirements. (they're all handled

Remove requirements. (they're all handled now) (whatwg r29) (changed by:
Ian Hickson)

Diffs for this change per section: 
  1.2 Conformance requirements
  http://people.w3.org/mike/diffs/html5/workers/Overview.1.22.html#conformance
  1.2.1 Dependencies
  http://people.w3.org/mike/diffs/html5/workers/Overview.1.22.html#dependencies
  1.3 Terminology
  http://people.w3.org/mike/diffs/html5/workers/Overview.1.22.html#terminology
  1.1 Tutorial
  http://people.w3.org/mike/diffs/html5/workers/Overview.1.22.html#tutorial

Current content per affected section: 
  http://dev.w3.org/html5/workers/Overview.html#conformance
  http://dev.w3.org/html5/workers/Overview.html#dependencies
  http://dev.w3.org/html5/workers/Overview.html#requirements
  http://dev.w3.org/html5/workers/Overview.html#terminology
  http://dev.w3.org/html5/workers/Overview.html#tutorial

Previously published WD content per affected section: 
  http://www.w3.org/TR/2008/WD-html5-20080610/single-page/#conformance
  http://www.w3.org/TR/2008/WD-html5-20080610/single-page/#dependencies
  http://www.w3.org/TR/2008/WD-html5-20080610/single-page/#requirements
  http://www.w3.org/TR/2008/WD-html5-20080610/single-page/#terminology
  http://www.w3.org/TR/2008/WD-html5-20080610/single-page/#tutorial

Cumulative diff: http://people.w3.org/mike/diffs/html5/workers/Overview.diff.html

http://dev.w3.org/cvsweb/html5/workers/Overview.html?r1=1.21&r2=1.22&f=h

http://html5.org/tools/web-apps-tracker?from=28&to=29

===================================================================
RCS file: /sources/public/html5/workers/Overview.html,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -d -r1.21 -r1.22
--- Overview.html 18 Jul 2008 10:11:55 -0000 1.21
+++ Overview.html 18 Jul 2008 10:14:02 -0000 1.22
@@ -183,17 +183,14 @@
     <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
+     <li><a href="#conformance"><span class=secno>1.2 </span>Conformance
       requirements</a>
       <ul class=toc>
-       <li><a href="#dependencies"><span class=secno>1.3.1
+       <li><a href="#dependencies"><span class=secno>1.2.1
         </span>Dependencies</a>
       </ul>
 
-     <li><a href="#terminology"><span class=secno>1.4 </span>Terminology</a>
+     <li><a href="#terminology"><span class=secno>1.3 </span>Terminology</a>
     </ul>
 
    <li><a href="#infrastructure"><span class=secno>2.
@@ -237,57 +234,7 @@
 
   <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>
+  <h3 id=conformance><span class=secno>1.2 </span>Conformance requirements</h3>
 
   <p>All diagrams, examples, and notes in this specification are
    non-normative, as are all sections explicitly marked non-normative.
@@ -323,7 +270,7 @@
    against running out of memory, or to work around platform-specific
    limitations.
 
-  <h4 id=dependencies><span class=secno>1.3.1 </span>Dependencies</h4>
+  <h4 id=dependencies><span class=secno>1.2.1 </span>Dependencies</h4>
 
   <p>This specification relies on several other underlying specifications.
 
@@ -347,7 +294,7 @@
      specification. <a href="#refsWebIDL">[WebIDL]</a></p>
   </dl>
 
-  <h3 id=terminology><span class=secno>1.4 </span>Terminology</h3>
+  <h3 id=terminology><span class=secno>1.3 </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

Received on Friday, 18 July 2008 10:15:35 UTC