Re: Data API

On 2/27/2012 12:59 PM, Cullen Jennings wrote:
> On topic of web sockets....
> It seems to me it would be very nice to be abel to use one our Data Channels anywhere that one could use a WebSocket. So if the web sockets interface is going to be re-factored to use AbstractMessenger, then I like how the proposals going but if not, I'd prefer to see DataChannel be defined to implement the WebSocket interface.

The current design is fairly well aligned with WebSockets, though 
obviously it allows things not possible in websockets.  I'll review the 
differences and see if the alignment can be closer.

> On topic of yet another signaling channel ....
> I am not keen on creating a new protocol to run over channel 0 to indicate signaling. We are going to need to be able to signal set up of SCTP in SDP to bring up even the first channel, so I'd like to look at see if we can just use this to set up other channels too. This brings DataStreams inline with MediaStreams in how you add them and such. I'd like to be able to think of Data Stream just like any other MediaStream as much as possible.

The downside is that several uses discussed would be infeasible (due to 
overhead) with a full renegotation required to add or remove a 
dataChannel - and the only reason we really have this is to allow 
bidirectionality to be set up, such that it looks more like WebSockets.  
As usual, if we go to pains to hide the ability to do this and slow it 
down (with no real benefit to the app), any app that wants low-latency 
creation will simply implement their own multiplexer over base 
unreliable or reliable dataChannels().

The app-level API for dataChannels is pretty similar to media streams, 
though there's a difference in that you're setting up a communications 
object, not attaching a stream gotten elsewhere (getUserMedia).

To be totally honest, the only reason I see a need to mention 
dataChannels at all in the SDP is to reduce overhead (either 
first-channel-create-time overhead, if we created the SCTP association 
on demand, or memory & startup-time overhead, if we created an 
association at the start of every PeerConnection).  In fact, I suspect 
the on-demand creation overhead would be low enough that we could do 
that, but others wanted it mentioned in SDP.

> On the topic of in order creation of Data streams...
> I'm not a fan of trying to guarantee that if the one sides add streams in a particular order, that order is preserved in how they come out of the callbacks on the far side. I'd rather just use labels to allow the applications on the two sides to keep them straight.

Sure, if you're ready to deal with 'label glare'.

> On the topic of label collision ...
> For the apps I want to write, if both sides create something with same label name at same time, I want just one stream created with that label with no extra work for me as an app programer. If I wanted two different streams, I would have created int he labels in a way that did not collide.

That was my original suggestion - but you do have to then deal with the 
non-glare case, where the labelled dataChannel has already been created 
by the other side, and that has caused a local object of that label to 
be created.  So you need to return an "already-created" error, or do 
something funky (and probably error-prone) which involves two objects at 
one side with the label and one on the other.  I'm ok with this; it was 
my original suggestion, but I'm not in any way tied to it, and I 
switched after thinking about the error cases.  I'm looking for 
something that will be easy to implement, and easy to use with minimal 
error cases for app developers.


> On setting per messages attributes such as reliable vs non reliable
> I like that API that Adam proposed where you can really on set attributes on a DataChannel and all the messages in the channel get that.

Agreed completely.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Monday, 27 February 2012 21:17:19 UTC