Re: A small proposal to cleanup DataChannel construction.

Anything specific in mind? If we feel the parameters are too closely
coupled to SCTP, I would prefer to try to abstract them so that app
developers can be agnostic to the underlying transport.


On Tue, Apr 22, 2014 at 10:50 AM, Robin Raymond <robin@hookflash.com> wrote:

>
> I like but the only issue I have is that RTCDataChannelParameters needs
> 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
> RTCDataChannelParameters need 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 <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 {
>
>   // ...
> }
>
>
>

Received on Tuesday, 22 April 2014 20:51:23 UTC