Re: A small proposal to cleanup DataChannel construction.

That's part of the trouble - we really don't know what other "future" 
transports might be like. We are allowing instance creation of an 
abstracting "data channel" which has abstract paramaters but are not 
sure they are truly abstract for every possible implementation of a data 
channel object that might come.

For example suppose there was an RUDP protocol offered (and I'm not that 
I'm saying anyone would add this). If RUDP works like TCP, except with 
UDP and does not support out of order params and is lossless then that 
"future data channel protocol" would have meaningless parameters (except 
possibly the ID). I suppose we could error if parameters were set wrong 
in that case or perhaps we can just assume every protocol must support 
these options. Or perhaps we ignore the problem until it is a problem.

Even if we mandate all future protocols support those data channel 
parameters, one thing I'm not clear is if WebIDL supports downcasting of 
dictionaries to be able to add additional stuff later for expanded new 
data channel protocol types.

-Robin


> Peter Thatcher <mailto:pthatcher@google.com>
> April 22, 2014 at 6:07 PM
> I think all of the things that we have (id, type, outOfOrder, 
> retransmits, protocol, preset, stream), I think we would want all of 
> those to work the same with other kids of data channels, and if we 
> really need something transport-type specific, we could always 
> subclass RTCDataChannelParameters, right?  I think for now we should 
> just do the simplest thing.  No need to burden developers with 
> unnecessary complexity.
>
>
>
> Robin Raymond <mailto:robin@hookflash.com>
> April 22, 2014 at 1:50 PM
>
> I like but the only issue I have is that RTCDataChannelParametersneeds 
> to be abstracted and there needs to be 
> RTCSctpDataChannelParametersderived from RTCDataChannelParameters. 
> Many of the options within "RTCSctpDataChannelParameters" will not 
> necessarily make sense for alternative transport types with 
> alternative optional "RTCDataChannelParameters" values for that 
> transport type.We can put common things like "ID" in a base 
> RTCDataChannelParameters.
>
> Does WebIDL allow downcasting of dictionaries or does 
> RTCDataChannelParametersneed to be an interface to support 
> downcasting? I know WebIDL allows dictionary inheritance and upcasting 
> is clear because of the example for WebIDL dictionaries, but 
> downcasting is not clearly defined.
>
> -Robin
>
>
> Peter Thatcher <mailto:pthatcher@google.com>
> April 15, 2014 at 1:04 PM
> I've noticed that createDataChannel and the RTCDataChannel contructor 
> overlap in functionality.  And since almost all of the current API is 
> based around using constructors instead of factory methods, I think we 
> can cleanup the overlap and make it consistent with the rest of the 
> API by doing the following:
>
> [Constructor(RTCDataTransport transport,
>
> RTCDataChannelParameters parameters)]
>
> interface RTCDataChannel : EventTarget {
>
>    readonly attribute RTCDataTransport transport;
>
>    readonly attribute RTCDataChannelParameters parameters;
>
>    void send (Object data);
>
>    attribute EventHandler ondata;
>
> };
>
>
> interface RTCDataTransport {
>
> }
>
>
> interface RTCSctpTransport : RTCDataTransport {
>
>  // ...
>
> }
>
>
> The difference is basically that:
> 1. We no longer have a createDataChannel method, and just call the 
> constructor instead.
> 2. RTCDataChannel no longer relies directly on SctpTransport. In the 
> future, we could have a different kind of DataTransport and have 
> DataChannels that work with it (we aren't as tightly coupled to SCTP).