Re: A small proposal to cleanup DataChannel construction.

I think until we have other types of data channels, we're not going to know
exactly what we'll need anyway.  I think we should just stick with what we
have here and solve that problem when it really comes up.


On Tue, Apr 22, 2014 at 3:32 PM, Robin Raymond <robin@hookflash.com> wrote:

>
> 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 <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 <robin@hookflash.com>
>  April 22, 2014 at 1:50 PM
>
> 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 {
>
>   // ...
> }
>
>
> 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).
>
>