Re: Idea: "Enable" function for stats members?

We've had a similar problem in the past where someone wants only part of
the stats and is paying a performance penalty for collecting all the
stats.  So I like the idea of being able to opt into stats, and maybe opt
out of, stats.

But could we not just make it a filter of some sort passed into getStats?
Perhaps something like this:
{
  "newStat": true,  // I want it
  "oldStat": false,  // I don't want it
}

But perhaps that's over-engineering it.

On Wed, Jan 4, 2017 at 1:16 AM Harald Alvestrand <harald@alvestrand.no>
wrote:

[Trying out pinging the list instead of / before raising an issue]

Happy new year, everyone!

In preparing for the switch from Chrome's nonstandard "getStats" call to
the standard, we've found some issues with the changeover, which we
think will be reflected in future work on extending the stats model.

Namely:

- There's no way of figuring out who uses a stats field. This means that
we can't tell if it's safe to delete it.

- There's no way to add "experimental" stats fields and have them only
impact implementations that actively want to use it. If we add a stat,
it will show up for everyone.

One possibility I've considered is to add API for this - something like
this:

pc.EnableExperimentalStats("peer-connection", "deeplyStrangeStatistic")
.then(function(neededEnabling) {
    if (neededEnabling) {
        log('deeplyStrangeStatistic is enabled for experimentation')
    } else {
        log('deeplyStrangeStatistic is now part of the spec, stop
bothering me')
    }
})
.catch(e => log('Cant enable deeplyStrangeStatistic, platform may not
have implemented it')

This would allow:

- JS to know if the statistic is availble or not
- The UA to collect stats on if anyone's using the non-standard statistic
- The UA to emit deprecation messages for "going to be deleted"
experimental statistics (because there's a JS call that can trigger the
deprecation message)

Floating this as an idea. Does it make sense to people?