Re: Data API: what is agreed, what is open

On 2/10/2012 2:15 PM, Timothy B. Terriberry wrote:
> Stefan Hakansson LK wrote:
>> I have a slight preference for bi-directional beacuse
>> a) It makes speccing the API a bit simpler since we need to specify only
>> one object type ("dataSocket" or something like that) that can send
>> ("send") and receive ("onmessage") rather than two different objects
>> (one "dataSendPort" and one "dataReceivePort")
>
> One difficulty is that if we want to leave open the possibility of
> per-packet ordered and reliable transmission flags, but start with
> per-channel settings fixed at channel creation time, then the receiver
> has to make a decision about what kind of channel to create before it
> can receive its first packet. That can have some surprising implications.

If we're bi-directional, we need to exchange some type of open-time 
metadata (which we probably need for other reasons anyways), so the 
channel type (or default channel type) can be included in that.  Even 
for unidirectional, we're talking about sending some sort of metadata, 
so the stream type could be signaled, if it ends up being needed (and 
I'm not sure it will).

> If you let the application decide, then somehow it has to make that
> decision before it can get access to the data channel object to receive
> data, even though it may not know or care which choice is best. If you
> base it off the flags on the first packet, then if a non-browser sender
> sends an unreliable packet followed by a reliable one, a browser on the
> receiving side will respond with reliable packets if the first one gets
> dropped, and unreliable packets if it doesn't.

(Though largely moot due to the comment I made above): It should never 
be connecting WebRTC data channels to non-WebRTC sources (unlike with 
media streams); any remote party we're connected to *should* follow the 
spec, and so not mix types.

Also, if we were ever to expand the spec to allow mixed packets in a 
dataChannel, I'd deem that a new type and so it would never be connected 
to a WebRTC implementation at the other end that didn't understand mixed 
channels.  Combine that with the already-agreed-to statement that the 
dataChannels are inherently application-specific, and I don't see a 
problem here.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Friday, 10 February 2012 21:34:36 UTC