W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2011

Re: Proposed data channel API

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 07 Nov 2011 14:59:05 +0100
Message-ID: <4EB7E429.8080700@alvestrand.no>
To: public-webrtc@w3.org
On 11/07/2011 02:51 PM, Stefan HÃ¥kansson LK wrote:
> On 11/07/2011 02:28 PM, 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.
> Agreed, but what does the app developer (that has just learned WS) 
> think? Would (s)he prefer that (more clumsy) model, or to learn a new 
> (but more pleasant) model?

The WebSocket API has one WebSocket object per connection, so if you 
have two channels across a PeerConnection, the model with multiple 
DataStream objects is more similar to WebSockets than one that depends 
on having an "index" parameter to the calls on PeerConnection.

>> 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 have the same view.
>>> What made me think again was re-reading the Streams API proposal
>>> <http://html5labs.interoperabilitybridges.com/streamsapi/>, explained
>>> a bit more in
>>> <http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1569.html>. 
>>> Here a proposal on more advanced stream functionalities is outlined.
>>> Basically the core is a Stream (meaning an object that has unspecified
>>> length), a Stream can be dealt with using StreamBuilders and
>>> StreamReaders.
>>> 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.
> I think I was a bit unclear. The proposal I referred to has not gotten 
> any traction really, so there is no point in aligning to it. I was 
> more asking if that kind of more advanced functionality is something 
> that is of interest, in that case we could steal stuff. And there 
> would also be a clear motive for a separate DataStream object.
> 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.
> If this is priority, then we should rather deal with data directly on 
> the PeerConnection (including passing "channel ID").
> I share the view that WS alignment would be nice, but so would perhaps 
> more advanced functionality.
> I guess that what I would really really like is some wep app developer 
> feedback!!!
Me too!
Received on Monday, 7 November 2011 13:59:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:26 UTC