- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 Sep 2017 14:26:06 +0000
- To: public-webrtc-logs@w3.org
@henbos Sorry, I was reacting to this being the first mention of any caching at all. In particular the introduction of this (non-normative?) allowance: *"An implementation MAY utilize caching for performance benefits and return the same result as a previous getStats() call. "* Is there normative support for this? This would seem to conflict with many MUST statements elsewhere in this spec and the WebRTC spec, and as such seems ambiguous, and best avoided. To the extent we want to disallow caching, I think specs do this by specifying the invariant guarantees an API MUST offer. These become the guarantees that must not be broken by any implementation optimizations; they define the boundaries within which implementations are implicitly allowed to experiment with things like caching, without a spec endorsing caching, or ingraining it in the API. If there are guarantees missing in this spec, I'm all for adding them. I was hoping they were there already, but if they're unclear, I'm all for making them more explicit. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-stats/pull/243#issuecomment-330239995 using your GitHub account
Received on Monday, 18 September 2017 14:25:59 UTC