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

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

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 8 Feb 2012 10:42:03 +0100
Message-ID: <4F32436B.1040307@ericsson.com>
To: public-webrtc@w3.org
As contributor:

On 02/07/2012 06:10 PM, 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
> * 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?

I have a slight preference for bi-directional beacuse
a) It makes speccing the API a bit simpler since we need to specify only 
one object type ("dataSocket" or something like that) that can send 
("send") and receive ("onmessage") rather than two different objects 
(one "dataSendPort" and one "dataReceivePort")
b) Better aligned to WS - easier for the web app developer to grasp
c) I expect many applications to exchange data rather than it going one 
way - so it would be natural
d) If the app developer wants uni-directional messaging it is simple to 
use a bi-directional channel in one direction only (and set up another 
for the back channel)
(but bi-directional is not something I will fight for - it is more a 
matter of taste)

> * 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")?
>
>
> 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 09:45:36 UTC

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