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

On 02/11/2012 12:57 AM, Cullen Jennings wrote:
>
> 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

I'm sorry if I went to far; the list of "agreed" is based on list 
discussions, on the feedback given to Justin's API proposal and on the 
discussion at both the TPAC f2f and at the interim (Feb 1st in MtView). 
I probably managed to do some extrapolation by mistake :-).

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

I think Justin's latest API draft is quite well aligned with WebSockets. 
That said, there is no need from the use cases so far to support 
separate channels (though we've heard from e.g. Randell that this is 
something the game community would like to see).

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

This is basically the data types that you can send/receive with 
WebSockets, so it is an alignment.

>
>> * 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 app should be able to determine if more and more data is being 
buffered locally - that is a sign that the app is trying to send more 
data than the channel can carry.

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

I have the same view.

>
>
>>
>>
>> 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 Monday, 13 February 2012 13:08:58 UTC