Re: Proposed data channel API

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