Re: Proposal for API for Data

On 04/10/2012 10:56 PM, Randell Jesup wrote:
> On 4/10/2012 4:45 PM, Timothy B. Terriberry wrote:
>> Randell Jesup wrote:

>>> We don't ack messages at the user protocol level; our definition had
>>> been planned to be a measure of the amount of data queued for
>>> transmission by the stack (depending on what the stack makes easy to
>>> get). We hadn't put a precise definition on it yet.
>>
>> It may be worth thinking about "what's useful for an application
>> developer", rather than "what the stack makes easy to get". Hopefully
>> those are the same, but of course that's not guaranteed.
>
> Agreed, though I care about both.  And bufferedAmount typically is
> actually just a crude indicator of "am I getting ahead of the channel"
> so the application can adapt and avoid inducing delays.  Actually far
> more useful than a single DataChannel's queued amount is the total
> queued across all channels (and that might be easier to get).  But that
> would be a very different api than WebSockets.

In one of the early API proposal for data (way back) there was actually 
possible to get the total buffered amount (sum of buffered amount for 
all data channels). I think this can be of great interest for the app to 
know for the reasons you point out, but I am not sure how to incorporate 
it in API. On the other hand, having the app get the buffered amount for 
all data channels and sum it up does not seem that difficult either.

And I agree, it will never be more than an indicator of that you're 
getting ahead of the channel.

>

Received on Wednesday, 11 April 2012 08:46:45 UTC