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