W3C home > Mailing lists > Public > public-html-commits@w3.org > July 2008

html5/workers Overview.html,1.21,1.22

From: Ian Hickson via cvs-syncmail <cvsmail@w3.org>
Date: Fri, 18 Jul 2008 10:14:04 +0000
To: public-html-commits@w3.org
Message-Id: <E1KJmyS-0007K2-It@lionel-hutz.w3.org>

Update of /sources/public/html5/workers
In directory hutz:/tmp/cvs-serv28117

Modified Files:
	Overview.html 
Log Message:
Remove requirements. (they're all handled now) (whatwg r29)

Index: Overview.html
===================================================================
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:14:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 9 October 2008 20:32:58 GMT