Re: Proposal: offerDataChannel in RTCOfferOptions

To step back for a minute, I can see several alternatives:

It seems like it would be reasonable to assume that someone might want
a data channel if they create a peer connection without any media or
data channels.

That implies the existence of an implied value for this option.

(BTW, I'm starting to find the proliferation of configuration option
dictionaries that are fed to essentially the same object a little
taxing.)

On 28 April 2015 at 10:17, Benjamin Schwartz <bemasc@google.com> wrote:
> On Tue, Apr 28, 2015 at 12:18 PM, 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 proposed constraint was for RTCOfferOptions, not RTCConfiguration, but
> leaving that aside, here's the comparison I'm thinking of:
>
> var pc = new RTCPeerConnection({yesIWantADataChannel: true});
> negotiate(pc).then(_ => {
>   setConnectionReady(true);
> });
>
> // In this app, datachannels are only created in response to certain user
> actions.
> this.onsomeuseraction = _ => {
>   var dc = pc.createDataChannel(getLabel());
>   useDataChannel(dc);
> };
>
> pc.ondatachannel = this.gotChannel;
>
> vs.
>
> var pc = new RTCPeerConnection();
> // The initial channel is not associated with a user action, so it's just a
> dummy
> // to get the right m-lines in the offer.
> var dc = pc.createDataChannel('dummyLabel');
> negotiate(pc).then(_ => {
>   setConnectionReady(true);
> });
>
> this.onsomeuseraction = _ => {
>   // The labels of useful channels must be limited so that they can be
>   // distinguished from the dummy channel.
>   var dc =
> pc.createDataChannel(getLabelThatDoesntCollideWithTheDummyChannel());
>   useDataChannel(dc);
> };
>
> pc.ondatachannel = (e) => {
>   // The incoming label must be checked (at least on the answering side), so
>   // that the dummy channel can be ignored.
>   if (e.channel.label === 'dummyLabel') {
>     return;
>   }
>   this.gotChannel(e);
> };
>
> More broadly, I think createDataChannel should be for creating data channels
> ... not for some weird side effect that allows you to avoid renegotiation.
> I think we should try to avoid creating situations where you are supposed to
> call createDataChannel, even though you don't actually want to create a data
> channel right now.
>
>>
>> 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 17:51:02 UTC