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

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, 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 
> <mailto: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
>     <mailto: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 <mailto:pthatcher@google.com>> wrote:
>
>             On Mon, Aug 24, 2015 at 2:47 PM, Randell Jesup
>             <randell-ietf@jesup.org <mailto: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 emailrandell-ietf@jesup.org <mailto: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