- From: poot <cvsmail@w3.org>
- Date: Tue, 10 Jul 2012 17:19:42 -0400
- To: public-html-diffs@w3.org
postmsg; hixie: Explain start() with an example. (whatwg r7171)
http://dev.w3.org/cvsweb/html5/postmsg/Overview.html?r1=1.120&r2=1.121&f=h
http://html5.org/tools/web-apps-tracker?from=7170&to=7171
===================================================================
RCS file: /sources/public/html5/postmsg/Overview.html,v
retrieving revision 1.120
retrieving revision 1.121
diff -u -d -r1.120 -r1.121
--- Overview.html 26 Jun 2012 19:59:02 -0000 1.120
+++ Overview.html 10 Jul 2012 21:19:32 -0000 1.121
@@ -216,7 +216,7 @@
<h1>HTML5 Web Messaging</h1>
- <h2 class="no-num no-toc" id="editor-s-draft-26-june-2012">Editor's Draft 26 June 2012</h2>
+ <h2 class="no-num no-toc" id="editor-s-draft-10-july-2012">Editor's Draft 10 July 2012</h2>
<dl><dt>Latest Published Version:</dt>
<dd><a href="http://www.w3.org/TR/webmessaging/">http://www.w3.org/TR/webmessaging/</a></dd>
<dt>Latest Editor's Draft:</dt>
@@ -350,7 +350,7 @@
</dl><p>The W3C <a href="http://www.w3.org/2008/webapps/">Web Applications
Working Group</a> is the W3C working group responsible for this
specification's progress along the W3C Recommendation track.
- This specification is the 26 June 2012 Editor's Draft.
+ This specification is the 10 July 2012 Editor's Draft.
</p>
@@ -386,8 +386,9 @@
<ol>
<li><a href="#introduction-0"><span class="secno">5.1 </span>Introduction</a>
<ol>
- <li><a href="#ports-as-the-basis-of-an-object-capability-model-on-the-web"><span class="secno">5.1.1 </span>Ports as the basis of an object-capability model on the Web</a></li>
- <li><a href="#ports-as-the-basis-of-abstracting-out-service-implementations"><span class="secno">5.1.2 </span>Ports as the basis of abstracting out service implementations</a></ol></li>
+ <li><a href="#examples"><span class="secno">5.1.1 </span>Examples</a></li>
+ <li><a href="#ports-as-the-basis-of-an-object-capability-model-on-the-web"><span class="secno">5.1.2 </span>Ports as the basis of an object-capability model on the Web</a></li>
+ <li><a href="#ports-as-the-basis-of-abstracting-out-service-implementations"><span class="secno">5.1.3 </span>Ports as the basis of abstracting out service implementations</a></ol></li>
<li><a href="#message-channels"><span class="secno">5.2 </span>Message channels</a></li>
<li><a href="#message-ports"><span class="secno">5.3 </span>Message ports</a>
<ol>
@@ -967,7 +968,73 @@
<pre>port1.postMessage(['hello', 'world'], 'http://example.com');</pre>
- <h4 id="ports-as-the-basis-of-an-object-capability-model-on-the-web"><span class="secno">5.1.1 </span>Ports as the basis of an object-capability model on the Web</h4>
+ <h4 id="examples"><span class="secno">5.1.1 </span>Examples</h4>
+
+ <p><i>This section is non-normative.</i></p>
+
+ <div class="example">
+
+ <p>In this example, two JavaScript libraries are connected to each
+ other using <code><a href="#messageport">MessagePort</a></code>s. This allows the libraries to
+ later be hosted in different frames, or in <code>Worker</code>
+ objects, without any change to the APIs.</p>
+
+ <pre><script src="contacts.js"></script> <!-- exposes a contacts object -->
+<script src="compose-mail.js"></script> <!-- exposes a composer object -->
+<script>
+ var channel = new MessageChannel();
+ composer.addContactsProvider(channel.port1);
+ contacts.registerConsumer(channel.port2);
+</script></pre>
+
+ <p>Here's what the "addContactsProvider()" function's
+ implementation could look like:</p>
+
+ <pre>function addContactsProvider(port) {
+ port.onmessage = function (event) {
+ switch (event.data.messageType) {
+ 'search-result': handleSearchResult(event.data.results); break;
+ 'search-done': handleSearchDone(); break;
+ 'search-error': handleSearchError(event.data.message); break;
+ // ...
+ }
+ };
+};</pre>
+
+ <p>Alternatively, it could be implemented as follows:</p>
+
+ <pre>function addContactsProvider(port) {
+ port.addEventListener('message', function (event) {
+ if (event.data.messageType == 'search-result')
+ handleSearchResult(event.data.results);
+ });
+ port.addEventListener('message', function (event) {
+ if (event.data.messageType == 'search-done')
+ handleSearchDone();
+ });
+ port.addEventListener('message', function (event) {
+ if (event.data.messageType == 'search-error')
+ handleSearchError(event.data.message);
+ });
+ // ...
+ port.start();
+};</pre>
+
+ <p>The key difference is that when using <code title="dom-EventTarget-addEventListener">addEventListener()</code>,
+ the <code title="dom-MessagePort-start"><a href="#dom-messageport-start">start()</a></code> method must
+ also be invoked. When using <code title="handler-MessagePort-onmessage"><a href="#handler-messageport-onmessage">onmessage</a></code>, the call to
+ <code title="dom-MessagePort-start"><a href="#dom-messageport-start">start()</a></code> is implied.</p>
+
+ <p>The <code title="dom-MessagePort-start"><a href="#dom-messageport-start">start()</a></code> method,
+ whether called explicitly or implicitly (by setting <code title="handler-MessagePort-onmessage"><a href="#handler-messageport-onmessage">onmessage</a></code>), starts the
+ flow of messages: messages posted on message ports are initially
+ paused, so that they don't get dropped on the floor before the
+ script has had a chance to set up its handlers.</p>
+
+ </div>
+
+
+ <h4 id="ports-as-the-basis-of-an-object-capability-model-on-the-web"><span class="secno">5.1.2 </span>Ports as the basis of an object-capability model on the Web</h4>
<p><i>This section is non-normative.</i></p>
@@ -1040,7 +1107,7 @@
capability to add a single contact.</p>
- <h4 id="ports-as-the-basis-of-abstracting-out-service-implementations"><span class="secno">5.1.2 </span>Ports as the basis of abstracting out service implementations</h4>
+ <h4 id="ports-as-the-basis-of-abstracting-out-service-implementations"><span class="secno">5.1.3 </span>Ports as the basis of abstracting out service implementations</h4>
<p><i>This section is non-normative.</i></p>
Received on Tuesday, 10 July 2012 21:19:44 UTC