Re: Proposed data channel API

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.

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.

>
> 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. 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.

                      Harald

Received on Monday, 7 November 2011 13:28:42 UTC