Re: A small proposal to cleanup DataChannel construction.

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 {
>
>  // ...
>
> }
>
>