Re: Proposed data channel API

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/>, 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!!!

>
>                        Harald
>

Received on Monday, 7 November 2011 13:52:33 UTC