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

On Feb 11, 2012, at 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
> 
>> 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. 
Assuming that channel maps to an SCTP stream and DataStream maps to an SCTP association, there is one
difference between using multiple channels of a singe DataStream and multiple channels, each belonging
to a single DataStream: The bandwidth which is used, since you are using multiple transport connections
versus one.
> 
> 
>> * 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. 
Please note, that
* You can, on a message base, select "in sequence" or "out of sequence" delivery.
* You can, on a message base, select "reliable" or "un-reliable" transfer.
These are orthogonal.

The question I have: What does "un-reliable" mean? At least in the BSD implementation of SCTP we
support:
(1) The message is transmitted once and the number of retransmissions is limited by a
    user specified number. So you could, for example, limit the number of retransmissions
    to zero.
(2) The message is only transmitted/retransmitted within a user specified amount of time.
    After that time, the stack will not transmit or retransmit it anymore.
(3) A buffer based one...
These policies (for PR-SCTP) can be selected on a per message base.
I'm not sure if you want to support multiple policies (even new ones in addition to the
above are possible), or only a single one (which one?). This needs to be specified.
> 
>> * The API should initially enable sending and receiving DOMString, Blob
>> and ArrayBuffer data
> 
> Like to know more but suspect I won't care 
I would be interested if the sending and receiving of user messages needs to be atomic.
In particular for large messages (I think someone said that messages in the order of 100MB
needs to be supported). This might require some buffering inside the JS layer.

Best regards
Michael
> 
>> * 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 Monday, 13 February 2012 10:38:17 UTC