- From: François Daoust via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Feb 2016 10:35:07 +0000
- To: public-secondscreen@w3.org
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