- From: poot <cvsmail@w3.org>
- Date: Fri, 9 Apr 2010 09:26:31 +0900 (JST)
- To: public-html-diffs@w3.org
device; hixie: There's not really any point talking about separate Client and Server objects here. Both will have to send config information back and forth to make the connection work anyway. (whatwg r4988) http://dev.w3.org/cvsweb/html5/html-device/Overview.html?r1=1.33&r2=1.34&f=h http://html5.org/tools/web-apps-tracker?from=4987&to=4988 =================================================================== RCS file: /sources/public/html5/html-device/Overview.html,v retrieving revision 1.33 retrieving revision 1.34 diff -u -d -r1.33 -r1.34 --- Overview.html 4 Apr 2010 06:34:10 -0000 1.33 +++ Overview.html 9 Apr 2010 00:26:05 -0000 1.34 @@ -285,7 +285,7 @@ <h1>HTML Device</h1> <h2 class="no-num no-toc" id="an-addition-to-html">An addition to HTML</h2> - <h2 class="no-num no-toc" id="editor-s-draft-4-april-2010">Editor's Draft 4 April 2010</h2> + <h2 class="no-num no-toc" id="editor-s-draft-9-april-2010">Editor's Draft 9 April 2010</h2> <dl><dt>Latest Published Version:</dt> <dd><a href="http://www.w3.org/TR/html-device/">http://www.w3.org/TR/html-device/</a></dd> <dt>Latest Editor's Draft:</dt> @@ -364,7 +364,7 @@ specification's progress along the W3C Recommendation track. - This specification is the 4 April 2010 Editor's Draft. + This specification is the 9 April 2010 Editor's Draft. </p><!-- UNDER NO CIRCUMSTANCES IS THE PRECEDING PARAGRAPH TO BE REMOVED OR EDITED WITHOUT TALKING TO IAN FIRST --><!-- relationship to other work (required) --><p>This specification is part of <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/">a larger specification</a> being produced by the <a href="http://www.whatwg.org/">WHATWG</a>. <!-- UNDER NO CIRCUMSTANCES IS THE FOLLOWING PARAGRAPH TO BE REMOVED OR EDITED WITHOUT TALKING TO IAN FIRST --> @@ -472,7 +472,8 @@ <code>video</code> elements.<p class="XXX">This again will be pinned down to a specific codec.<h3 id="peer-to-peer-connections"><span class="secno">2.2 </span>Peer-to-peer connections</h3><p class="XXX">This section will be moved to a more appropriate location in due course; it is here currently to keep it near the <code><a href="#devices">device</a></code> element to allow reviewers to look at it.<pre class="idl">[NoInterfaceObject] -interface <dfn id="abstractpeer">AbstractPeer</dfn> { +[Constructor(in DOMString serverConfiguration)] +interface <dfn id="connectionpeer">ConnectionPeer</dfn> { void sendText(in DOMString text); attribute <span>Function</span> ontext; // receiving @@ -482,35 +483,24 @@ void sendFile(in File file); attribute <span>Function</span> onfile; // receiving - attribute <a href="#stream">Stream</a> localStream; // video/audio to send - readonly attribute <a href="#stream">Stream</a> remoteStream; // video/audio from remote peer - attribute <span>Function</span> onstreamchange; // when the remote peer changes whether the video is being sent or not + void addStream(in Stream stream); + void removeStream(in Stream stream); + readonly attribute Stream[] localStreams; + readonly attribute Stream[] remoteStreams; + attribute <span>Function</span> onstream; // receiving + + void <span title="dom-ConnectionPeer-getLocalConfiguration">getLocalConfiguration</span>(in <a href="#connectionpeerconfigurationcallback">ConnectionPeerConfigurationCallback</a> callback); // maybe this should be in the constructor + void <span title="dom-ConnectionPeer-addRemoteConfiguration">addRemoteConfiguration</span>(in DOMString configuration); + void close(); // disconnects and stops listening attribute <span>Function</span> onconnect; attribute <span>Function</span> onerror; attribute <span>Function</span> ondisconnect; }; -[Constructor(in DOMString serverConfiguration)] -interface <dfn id="peertopeerserver">PeerToPeerServer</dfn> : <a href="#abstractpeer">AbstractPeer</a> { - void <span title="dom-PeerToPeerServer-getClientConfiguration">getClientConfiguration</span>(in <a href="#peertopeerconfigurationcallback">PeerToPeerConfigurationCallback</a> callback); -<!--(doesn't make much sense to not accept it, after going to all the effort of setting it up) - attribute <span>Function</span> onincoming; // incoming call detected - void accept(); // accepts incoming call - void reject(in optional DOMString message); // explicitly rejects incoming call ---> - void close(); // disconnects and stops listening -}; - -[Constructor] -interface <dfn id="peertopeerclient">PeerToPeerClient</dfn> : <a href="#abstractpeer">AbstractPeer</a> { - void <span title="dom-PeerToPeerClient-addConfiguration">addConfiguration</span>(in DOMString configuration); - void close(); // disconnects -}; - [Callback=FunctionOnly, NoInterfaceObject] -interface <dfn id="peertopeerconfigurationcallback">PeerToPeerConfigurationCallback</dfn> { - void <span title="dom-PeerToPeerConfigurationCallback-handleEvent">handleEvent</span>(in <a href="#peertopeerserver">PeerToPeerServer</a> server, in DOMString configuration); +interface <dfn id="connectionpeerconfigurationcallback">ConnectionPeerConfigurationCallback</dfn> { + void <span title="dom-ConnectionPeerConfigurationCallback-handleEvent">handleEvent</span>(in <a href="#connectionpeer">ConnectionPeer</a> server, in DOMString configuration); };</pre><p class="XXX">...<div class="XXX"> <p>This relies on some currently hypothetical other standard to @@ -518,53 +508,54 @@ <ul><li>The format of server configuration strings. <li>The format of client configuration strings. - <li>The protocols that servers and clients use to talk to third-party servers mentioned in the server configuration strings. - <li>The protocols that servers and clients use to talk to each other. + <li>The protocols that clients use to talk to third-party servers mentioned in the server configuration strings. + <li>The protocols that clients use to talk to each other. </ul></div><div class="example"> - <p>Server:</p> + <p>When two peers decide they are going to set up a connection to + each other, they both go through these steps. The serverConfig + comes from a third-party server they can use to get things like + their public IP address or to set up NAT traversal. They also have + to send their respective configuration to each other using the same + out-of-band mechanism they used to establish that they were going + to communicate in the first place.</p> <pre>var serverConfig = ...; // configuration string obtained from server // contains details such as the IP address of a server that can speak some // protocol to help the client determine its public IP address, route packets // if necessary, etc. -var local = new PeerToPeerServer(serverConfig); -local.getClientConfiguration(function (configuration) { +var local = new ConnectionPeer(serverConfig); +local.getLocalConfiguration(function (configuration) { if (configuration != '') { ...; // send configuration to other peer using out-of-band mechanism } else { // we've exhausted our options; wait for connection } -});</pre> - - <p>Client:</p> +}); - <pre>var local = new PeerToPeerClient(); function ... (configuration) { // called whenever we get configuration information out-of-band - local.addConfiguration(configuration); -}</pre> - - <p>Both client and server:</p> + local.addRemoteConfiguration(configuration); +} - <pre>local.onconnect = function (event) { +local.onconnect = function (event) { // we are connected! local.sendText('Hello'); - local.localStream = ...; // send video - local.onstreamchange = function (event) { + local.addStream(...); // send video + local.onstream = function (event) { // receive video // (videoElement is some <video> element) - videoElement.src = local.remoteStream.URL; + if (local.remoteStreams.length > 0) + videoElement.src = local.remoteStreams[0].URL; }; };</pre> </div><p class="warning">To prevent network sniffing from allowing a - fourth party to establish a connection to the - <code><a href="#peertopeerserver">PeerToPeerServer</a></code> using the information sent out-of-band - to the <code><a href="#peertopeerclient">PeerToPeerClient</a></code> and thus spoofing the client, - the configuration information should always be transmitted using an - encrypted connection.<h2 class="no-num" id="references">References</h2><!--REFS--><p>All references are normative unless marked "Non-normative".</p><!-- Dates are only included for standards older than the Web, + fourth party to establish a connection to a peer using the + information sent out-of-band to the other peer and thus spoofing the + client, the configuration information should always be transmitted + using an encrypted connection.<h2 class="no-num" id="references">References</h2><!--REFS--><p>All references are normative unless marked "Non-normative".</p><!-- Dates are only included for standards older than the Web, because the newer ones keep changing. --><dl><dt id="refsFILEAPI">[FILEAPI]</dt> <dd><cite><a href="http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html">File API</a></cite>, A. Ranganathan. W3C.</dd>
Received on Friday, 9 April 2010 00:27:02 UTC