W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2012

Re: Data API symmetry

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 26 Apr 2012 15:49:24 +0200
Message-ID: <4F995264.1060900@ericsson.com>
To: public-webrtc@w3.org
On 04/25/2012 05:21 PM, Harald Alvestrand wrote:
> This line from case B #2 made me have an opinion.
>
> On 04/25/2012 04:04 PM, Adam Bergkvist wrote:
>>
>>
>>      viaWebServer.send("setup extra channel");
>
>
> I am not happy with interfaces that necessitate going through the server
> to set up channels.

To me it seems that the absolutely most common case would be that the 
same application is used at A and B. A natural design pattern could be 
to set up all data channels needed as soon as the 
PeerConnection-connection is established. And this includes the channels 
that would only be used if the user happens to perform a specific 
action. After all, the cost of establishing channels that are 
potentially unused is close to zero if I understand right.

So I would implement Case B for approach #2 as Case A:

peerConn.onopen = function () {
      chatDataChan = peerConn.createDataChannel("chat", chatSettings);
      chatDataChan.onopen = startChat;
      chatDataChan.onmessage = showChatMessage;

      extraDataChan = peerConn.createDataChannel("extra", extraSettings);
      extraDataChan.onopen = startExtra;
      extraDataChan.onmessage = onExtraMessage;
};

with the knowledge that channel "extra" may not be used at all.

Given this I have a slight preference for #2 as the app does not need to 
keep track of who was initiator (caller), and that there is no label 
glare to handle. And as pointed out, extra channels can be created on 
demand without going through the server also with approach #2 by using 
an existing one to signal (this is a bit more cumbersome than on demand 
channels with approach #1 though).


Stefan
Received on Thursday, 26 April 2012 13:49:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:49:55 GMT