Re: Proposed data channel API

On Mon, Nov 7, 2011 at 8:51 AM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> 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?
>
>
>
>> 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/<http://html5labs.interoperabilitybridges.com/streamsapi/>>,
>>> explained
>>> a bit more in
>>> <http://lists.w3.org/Archives/**Public/public-webapps/**
>>> 2011JulSep/1569.html<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!!!
>

Agreed - will be talking to some potential customers of this API this week.

>
>
>>                       Harald
>>
>>
>