- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Thu, 26 Apr 2012 15:49:24 +0200
- 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 UTC