W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2012

Re: Data API: what is agreed, what is open

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 07 Feb 2012 17:43:45 -0800
Message-ID: <4F31D351.5010903@alvestrand.no>
To: public-webrtc@w3.org
Speaking as contributor: I agree with the "agreed" points, with one 
clarification needed.

On 02/07/2012 09:10 AM, Stefan Hakansson LK wrote:
> Hi all,
> trying to summarize the discussion on the Data API, I come to this:
> Agreed
> ======
> * The API should allow for the application to use multiple channels
> (without having to to do muxing in the app)
> * The API should allow the application to select reliable or unreliable
> transmission (where "reliable" also means "in order delivery")
> * The API should initially enable sending and receiving DOMString, Blob
> and ArrayBuffer data

Query: Is there a difference between a Blob and an ArrayBuffer that we 
intend to have visible on the wire?
If yes, we have 3 types of data rather than WebSockets' 2 types; if no, 
we need some local function at the receiver to say whether he wants to 
receive blobs or ArrayBuffers.

> * The API should allow the application to check if data is being
> buffered (so that it can adjust the send rate)
> * The API should be designed to allow extension in functionality (e.g.
> set priority, set that in-order delivery is not to be used for reliable,
> etc.) and data types (e.g. to introduce Stream once the WebApps WG
> defines it)
> Open
> ====
> * Should the API be uni- or bi-directional?
> * Should there be a specific "open" signal to the application (or should
> the object dealt with when sending only be made available when
> transmission is possible), or should data be buffered until it can be
> transmitted (i.e. the app can always "send")?
One thought about buffering:
For reliable data, the amount buffered can be limited by just not 
accepting data from the SCTP layer, thus forcing the window closed.
For unreliable data .... well, it was unreliable anyway.

So I don't think we have to worry about infinite buffers here.
> We would like comments, both if you agree to what we state as 
> "agreed", and input on what you prefer on the open issues. And of 
> course other things we have a agreement on, and other things that are 
> open.
> Stefan for the chairs
Received on Wednesday, 8 February 2012 01:46:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:27 UTC