Re: Proposed data channel API

On 11/07/2011 02:59 PM, Harald Alvestrand wrote:
> 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.

I guess that in practice embed the "index" in the message when using WS. 
Plus there is some discussion on adding a multiplex layer to WS (but I 
don't know if the API has been discussed). The big difference would be 
that while PeerConnection (at least if SCTP is used) will also multiplex 
on the transport; in WS you would get stuck behind data already "sent":

It is a bit weird to me that you can create a DataStream, which has a 
send method, but you can't send (or receive); all this depends on 
PeerConnection. Would its ready state be LIVE or ENDED if not added to a 
PC? Once a WebSocket is open you can send and receive; the same would be 
true if send operated on a PeerConnection.

A MediaStream can be used to display locally, or with a canvas, or 
whatever, but a DataStream has no meaning without a PeerConnection.

I really don't have a strong view, I just wanted this discussed.

>
>>
>>>
>>> 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 15:20:32 UTC