{"action":"opened","issue":{"url":"https://api.github.com/repos/w3c/netinfo/issues/27","labels_url":"https://api.github.com/repos/w3c/netinfo/issues/27/labels{/name}","comments_url":"https://api.github.com/repos/w3c/netinfo/issues/27/comments","events_url":"https://api.github.com/repos/w3c/netinfo/issues/27/events","html_url":"https://github.com/w3c/netinfo/issues/27","id":109588559,"number":27,"title":"Clarify onchange: NQE compatible? use Performance Timeline instead?","user":{"login":"igrigorik","id":10652,"avatar_url":"https://avatars.githubusercontent.com/u/10652?v=3","gravatar_id":"","url":"https://api.github.com/users/igrigorik","html_url":"https://github.com/igrigorik","followers_url":"https://api.github.com/users/igrigorik/followers","following_url":"https://api.github.com/users/igrigorik/following{/other_user}","gists_url":"https://api.github.com/users/igrigorik/gists{/gist_id}","starred_url":"https://api.github.com/users/igrigorik/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/igrigorik/subscriptions","organizations_url":"https://api.github.com/users/igrigorik/orgs","repos_url":"https://api.github.com/users/igrigorik/repos","events_url":"https://api.github.com/users/igrigorik/events{/privacy}","received_events_url":"https://api.github.com/users/igrigorik/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-10-02T23:20:01Z","updated_at":"2015-10-02T23:20:01Z","closed_at":null,"body":"From: https://groups.google.com/a/chromium.org/d/msg/blink-dev/tU_Hqqytx8g/BeB5MsxbAwAJ\r\n\r\n> On Wed, Sep 30, 2015 at 12:43 PM, Yoav Weiss <yoav@yoav.ws> wrote:\r\n> We definitely should give developers the raw bandwidth and RTT data and let them build bandwidth estimation on top of that (assuming it has no privacy concerns). *But* that raw data cannot be exposed as a single point in time while expecting for it to be useful. We should expose such data as the continuous stream that it is, most probably on top of PerformanceTimeline.\r\n\r\n---\r\n\r\n> On Thu, Oct 1, 2015 at 2:30 PM, Ryan Sleevi <rsleevi@chromium.org> wrote:\r\n>> On Thu, Oct 1, 2015 at 2:18 PM, Ilya Grigorik <igrigorik@google.com> wrote:\r\n>>> On Thu, Oct 1, 2015 at 1:17 AM, Yoav Weiss <yoav@yoav.ws> wrote:\r\n>>> Looking at the current processing model for onchange, it becomes even more obvious that the current spec cannot sit well with NQE based estimations as the downlinkMax value should change only when the underlying network connection changed, and when it does, onchange should fire.\r\n\r\n>> \"If the underlying connection technology changes (in either connection type or maximum downlink speed)\" [1] ... Hmm, I think I see where I confusion is. My claim that we're NQE-compatible is based on \"or maximum downlink speed changes\" reading of above sentence, where \"maximum downlink speed\" is allowed to be adjusted based on network weather. Admittedly, not the greatest wording (I'm to blame :-)). I do agree that we should not limit notifications to changes to \"underlying connection type\".  \r\n\r\n>> \"If the properties of the connection change (e.g. changes in connection type, downlink speed, or other criteria), the user agent must run the steps to update the connection values...\" ~~ would something like that clarify our intent?\r\n\r\n> I think it's still unclear whether or not we want the singular value to be NQE-compatible. You've put forward the argument it can be (with slight spec changes), but from Alex's remarks, and from Yoav's, and from mine, I think there's some concern that making it NQE compatible makes it less appealing to developers.\r\n\r\n"}}