- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Wed, 1 Nov 2017 22:22:42 +0000
- To: "public-ortc@w3.org" <public-ortc@w3.org>
- CC: "pthatcher@google.com" <pthatcher@google.com>
Peter said (reviewing https://github.com/w3c/ortc/pull/793) "I'm not a fan of this model of supporting buffering. Two reasons: It only provides control for buffering on the send/write side, not on the read/receive side. It's clunky. On the other hand, it is easy to specify and implement, and I think that it's possible to implement the API I would prefer (waitForWritable) on top of it. If we came up with a matching buffering solution for the read/receive side, I could overlook the clunkyness and look at its good characteristics. But I feel strongly that we should figure out a solution for both sides of buffering before proceeding with either." [BA] Agree that it should be possible to implement waitForWritable on top of bufferedAmountLow/onbufferedamount low. I didn't propose a matching solution or reading because adjusting a bufferedAmountThreshold attribute to control readable event firing makes less sense than for write. For example, if you don't always want to read the same amount, you'd need to continually adjust the read-related bufferedAmountThreshold attribute. That's verges on "horrible" (the next level of ugly beyond "clunky").
Received on Wednesday, 1 November 2017 22:23:06 UTC