Re: [presentation-api] bufferedAmount property on PresentationConnection

These are good points. I suspects we can find workarounds, e.g. using 
specific values for `bufferedAmount` to avoid introducing additional 
requirements on the data channel. The property could always return `0`
 when IPC is used as it probably does not introduce noticeable 
delivery lags from an application perspective. Similarly, a `-1` value
 (or a separate flag) could mean "I do not know".

The main question for me is whether such a feature is needed. My 
understanding is that congestion control got added to WebSockets and 
RTCDataChannel because developers asked for it, in particular to 
control the sending of large chunks of data. Some of it can probably 
be implemented at the application level, through "ack" messages from 
the other side for instance.

Unless people in the group think that it must be added to the spec, I 
would suggest not to introduce congestion control and rather ask 
people for feedback on whether such a mechanism should be added to the
 spec when we issue the call for wide review.

-- 
GitHub Notification of comment by tidoust
Please view or discuss this issue at 
https://github.com/w3c/presentation-api/issues/241#issuecomment-179761968
 using your GitHub account

Received on Thursday, 4 February 2016 10:35:13 UTC