Re: Proposed data channel API

On 11/7/2011 8:28 AM, Harald Alvestrand wrote:
> On 11/07/2011 02:03 PM, Stefan Håkansson LK wrote:
>> (As individual):
>>
>> I am having some problem to decide what I think of this proposal.
>>
>> My initial feeling was that there is no role for the DataStream
>> interface. We have MediaStreams, but those are different since they
>> are not produced by the application (but by e.g. microphones and
>> cameras) nor consumed by the application (but by media elements).
>> Basically they are there to give the application some means to control
>> stuff that is produced and consumed in lower layers.
>>
>> With data it is different. The application produces ('send') and
>> consumes data ('onmessage') directly, so having an object outside
>> PeerConnection makes little sense. Further, things like priority has
>> no meaning (?) outside the actual transport.
>>
>> So far my thinking was in the direction that the data channel should
>> be in a PeerConnection only. We could have things like 'setupData',
>> 'send' methods with different channels, priority and reliability as
>> options, bufferedAmount attributes to read an so on. Basically it
>> would be similar to WebSockets, with the addition of channels,
>> priority and a non-reliable mode.

> If there is to be a concept of different data channels, I would much
> prefer them to be separate objects rather than having to pass a "channel
> ID" parameter to lots of functions.
>
> The two approaches are in practice identical under the hood (on the
> procedural programmer's theory that an object is "just" a fancy way of
> specifiying the first argument to its methods), but I find the explicit
> object style more pleasant to program with.

It's a style issue, but one that's largely in keeping with 'modern' 
currents in programming style, I'd say.

> Previous discussion seemed to indicate that if we offered just a single
> data channel on a PeerConnection, the first thing people would do was to
> add multiplexing, so it was better if multiple data channels was an
> explicitly available function on the API. It's also cheap to support on
> SCTP, if I understand correctly.

I agree; a single data connection is a problem - even if you multiplex, 
it gets complex to avoid head-blocking and other issues, and then 
supporting reliable channels when you multiplex gets complex.

>> If this is the direction we should go, then there is definitely a role
>> for a DataStream interface, but perhaps it should be extended a bit
>> (to be more similar to the Stream API).
>>
>> What do others think?
> Similarity is good. But I believe the lack of a record-delimited API for
> TCP was a mistake 30 years ago, and that we shouldn't repeat it here.
> Increasing the similarity to WebSockets would be higher on my priority
> list.

Agree strongly about TCP (even if record-delimited wasn't the default); 
I remember for implementing a P2P networked filesystem on the Amiga we 
were using RDP for that very reason (this was around 1991 or so).  And I 
agree WebSockets is a more appropriate model, though I'll admit I'm not 
fully up-to-speed on the WebSocket spec.


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Monday, 7 November 2011 16:12:47 UTC