Re: PR for adding RTCSctpTransport, PeerConnection.getSctpTransports(), and RTCDataChannel.transport

I agree with .dataTransport.  It sounds better.  I'll change it.

On Fri, Aug 28, 2015 at 1:26 AM, Randell Jesup <randell-ietf@jesup.org>
wrote:

> On 8/27/2015 5:27 PM, Justin Uberti wrote:
>
> We should probably be consistent with how the properties for other
> transports, e.g. IceTransport and DtlsTransport, are named. Looking at PR
> <https://github.com/w3c/webrtc-pc/pull/241/files>
> https://github.com/w3c/webrtc-pc/pull/241/files, everything is named
> .transport.
>
> .transport is clearly too general for something on PeerConnection, so I
> prefer either A, .sctpTransport, or a new Option C, .dataTransport.
>
>
> I prefer .dataTransport.  SCTP is mostly hidden under-the-hood from the
> DOM side.
>
>
>
> On Tue, Aug 25, 2015 at 6:18 PM, Peter Thatcher <pthatcher@google.com>
> wrote:
>
>> I have changed the PR so there is only one SctpTransport per
>> PeerConnection.  It's much smaller now :).
>>
>>
>> How, for the fun part, the bikeshedding!
>>
>>
>> Do we want
>>
>> Option A: PeerConnection.sctpTransport
>>
>> or
>>
>> Option B: PeerConnection.sctp
>>
>> ?
>>
>>
>>
>> .sctpTransport is more like ".transport"
>> .sctp is shorter and more like ".dtmf"
>>
>>
>> I prefer Option B, ".sctp", so have put that in the PR.  If you prefer a
>> different color of shed, please let me know.
>>
>>
>>
>> On Tue, Aug 25, 2015 at 5:58 PM, Justin Uberti < <juberti@google.com>
>> juberti@google.com> wrote:
>>
>>> I agree that single SctpTransport for 1.0 is the right way to go. We
>>> already have the ability to have multiple data channels on a transport, so
>>> having N channels * M transports isn't buying us much.
>>>
>>> And if we decide we need multiple transports later for some reason, the
>>> cost of backtracking on this issue would be low.
>>>
>>> On Mon, Aug 24, 2015 at 2:56 PM, Peter Thatcher < <pthatcher@google.com>
>>> pthatcher@google.com> wrote:
>>>
>>>> On Mon, Aug 24, 2015 at 2:47 PM, Randell Jesup <
>>>> <randell-ietf@jesup.org>randell-ietf@jesup.org> wrote:
>>>>
>>>>> On 8/24/2015 5:42 PM, Bernard Aboba wrote:
>>>>>
>>>>>
>>>>>
>>>>> *Peter asked: *
>>>>>
>>>>>
>>>>>
>>>>> “So, the big questions for the WG are:
>>>>>
>>>>>
>>>>>
>>>>> 1.    Should we allow multiple SctpTransports per PeerConnection?
>>>>>
>>>>> [BA] Personally, I don’t see a need for this.
>>>>>
>>>>>
>>>>> Multiple SctpTransports - that would require extra complexity for
>>>>> createDataChannel, etc.
>>>>>
>>>>
>>>> createDataChannel would be the same.  It's the
>>>> PeerConnection/SctpTransport that would be slightly more complex, since a
>>>> PeerConnection would have more than on SctpTransport.
>>>>
>>>>
>>>>
>>>>
>>>>> What's the usecase?  What's the advantage?  Right now I don't see
>>>>> anything compelling here, but perhaps there's a usecase I'm not considering.
>>>>>
>>>>
>>>> ​ At IETF 93, the desire to have different properties on different data
>>>> channels that are really per-association was raised (I believe priority was
>>>> the property in question).  So if you had multiple SctpTransports, it would
>>>> allow multiple associations and different per-association properties for
>>>> each one.
>>>>
>>>> If we say "In 1.0, there is only 1 SctpTransport;  Save multiple
>>>> SctpTransports for 1.1", I'd be fine with that, too.  But when I wrote the
>>>> PR, I thought was worth seeing how it would look, and after I wrote it, I
>>>> thought, "well, that's not so bad, why not allow it?".
>>>>
>>>> ​
>>>>
>>>>
>>>>
>>>>> --
>>>>> Randell Jesup -- rjesup a t mozilla d o t com
>>>>> Please please please don't email randell-ietf@jesup.org!  Way too much spam
>>>>>
>>>>>
>>>>
>>>
>>
>
>
> --
> Randell Jesup -- rjesup a t mozilla d o t com
> Please please please don't email randell-ietf@jesup.org!  Way too much spam
>
>