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

On Feb 7, 2012, at 10:10 AM, Stefan Hakansson LK wrote:

> Hi all,
> 
> trying to summarize the discussion on the Data API, I come to this:
> 

Hmmm - I did not realize we had agreed to any of theses but no real objections- few comments

> Agreed
> ======
> * The API should allow for the application to use multiple channels
> (without having to to do muxing in the app)

I don't care if we have this or not. On the pro side, it is something SCTP provides. On the con side, none of our causes cases need it as far as I can tell. And you can always set up more than one DataStream. It does make it harder to replace SCTP with a TCP like thing if we find problems with SCTP. I do worry that channels will make this hard to use an API that matches up with websockets. 


> * The API should allow the application to select reliable or unreliable
> transmission (where "reliable" also means "in order delivery")

Yes - and to be clear, I care more about "unreliable" deliver than reliably. As soon as you select "reliable" in SCTP, it means you basically don't care about real time and thus you probably could have sent that data over websockets via the server. The thing I can't do that way is real time data and thus the thing I really need here is "unreliable". That said, I do think we should have "reliable" as well. 

> * The API should initially enable sending and receiving DOMString, Blob
> and ArrayBuffer data

Like to know more but suspect I won't care 

> * The API should allow the application to check if data is being
> buffered (so that it can adjust the send rate)

uh - I have no idea what this even means. Of course it is buffered - it's a transport. Need to know more. 

> * 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)

In general agree, but having a hard time seeing what this means

> 
> Open
> ====
> * Should the API be uni- or bi-directional?

I will argue very strongly for bi-directional. It makes is much easier to to protocol where you send a request and expect a response to that request. It's what programmer expect. There pretty much no reason not to. 

> * 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")?

It should not buffer data before open because then it is hard to deal with what error to return if there is an error forming the data. (perhaps it returns an error if you try and send before it is open). The application should find out it is "open" in a way that mirrors how it works for audio and video streams. 


> 
> 
> 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, 10 February 2012 23:58:06 UTC