Re: Proposal: offerDataChannel in RTCOfferOptions

What is the material difference between:

var pc = new RTCPeerConnection({yesIWantADataChannel: true});
negotiate(pc).then(_ => {
   var dc = pc.createDataChannel();
   useDataChannel(dc);
});

...and:

var pc = new RTCPeerConnection();
var dc = pc.createDataChannel();
negotiate(pc).then(_ => {
   useDataChannel(dc);
});

Both require that you do something before negotiating.

If the suggestion were to have a data channel created by default, with
an option instead to suppress that behaviour; *that( I might be able
to understand.

On 28 April 2015 at 08:53, Peter Thatcher <pthatcher@google.com> wrote:
> I like this idea because I've had many bugs/questions from people new to the
> API where somewhere says something like "I call createOffer, and there's
> nothing in there for data channels".  And saying "you have to call
> createDataChannel before calling createOffer" can be awkward and confusing
> because tthe natural mental model of people new to PeerConnection for the
> purpose of using data channels seems to be:
>
> 1.  Setup a PeerConnection (with createOffer, createAnswer,
> setLocalDescription, setRemoteDescription)
> 2.  Create a data channel (with createDataChannel)
> 3.  Send data on the data channel
>
> But then I have to explain that the "right" way to do things is:
>
> 1. Create a useless data channel
> 2. Setup a PeerConnection
> 3. Send data on the previously useless data channel, or create a new one.
>
> So, the "right" way is non-intuitive and awkward, and the natural thing to
> do is wrong.  A "use data channels" flag such as "offerDataChannel" would be
> more clear.
>
>
>
> On the other hand, it does add a tiny bit of API surface for which we'll
> have to answer questions like "what if the offerDataChannel is set to false
> after data channels are up and running?".  So it seems like a small gain for
> a small cost.  On balance, I'm in favor of it since we pay the small cost
> and the developers get the small gain.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Apr 27, 2015 at 3:01 PM, Benjamin Schwartz <bemasc@google.com>
> wrote:
>>
>> Currently, RTCPeerConnection has "offerToReceiveVideo" in the
>> RTCOfferOptions, which is a convenience to allow creating an offer with a
>> m-line for video without first having to attach a video MediaStreamTrack.
>> This is useful; without it, pages would have to attach a track and then
>> renegotiate, even if they only want to receive video.
>>
>> However, with data channels, we don't have this convenience.  The offerer
>> must call createDataChannel before createOffer, or suffer a renegotiation,
>> even if they have no immediate need for a data channel.
>>
>> So what do you think of adding a boolean "offerDataChannel" attribute to
>> RTCOfferOptions, parallel to "offerToReceive*"?  I think that would be
>> easier to use.
>>
>> --Ben
>
>

Received on Tuesday, 28 April 2015 16:18:40 UTC