Re: Proposal: offerDataChannel in RTCOfferOptions

On Tue, Apr 28, 2015 at 9:18 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> 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.
>
>
​The second leads to more confusion, and least judging by how many people
come to be me confused.



> 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.
>
>
​I'd be even more happy if "offerDataChannel" were true by default, just
like "offerToReceiveAudio" is. ​




> 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
> >
> >
>