Re: Proposal: offerDataChannel in RTCOfferOptions

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
>