Concluding "Data API: what is agreed, what is open"

Trying to summarize the input (and thanks to all that supplied valuable 
input) we come to:

* Most seem to support the list of things put up as "Agreed".

* On the list of "Open" items it seems like:
** There seems to be a slight preference for bi-directional
** There seems to be a preference for an indication to the application 
when it can start sending data (rather than buffering until "open")

Other comments made include:
============================
* Need to decide how the JS API can be designed to feed back
out-of-order and loss data for unreliable data;
** One proposal was to have meta data in the onmessage event
** Another comment said "It was unreliable anyway"

* Unreliable is more important than reliable (but we should do both)

* Noted that even if there is a possibility to check how much data that 
is buffered (i.e. not transmitted yet), this would only tell what is 
buffered in user land, not in kernel

* There may be a need to define a maximum size of objects to send

* What is meant by unreliable should be defined

* Question if there is a difference between a Blob and an ArrayBuffer 
that we intend to have visible on the wire?

* There seem to be some more work required on STCP in combination with 
bi-directional _if_ switching between reliable/unreliable per message is 
allowed

* We should stick to datagrams and not add an additional 
fragmentation/reassembly layer

* Some input pointing in the direction that aligning the API to the 
WebSocket API makes sense

(Hopefully the discussion was captured reasonably well).

Based on the above the chairs have asked the Editors to draft an API 
proposal.

Stefan for the chairs

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?
> * 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 Friday, 17 February 2012 12:29:41 UTC