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

On 01/20/2017 08:13 PM, Peter Thatcher wrote:
> 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.

FIltering stats in Javascript is simple in code lines. If we could
eliminate a whole stats category, so that we could eliminate some thread
hop, that would have some performance benefit. but the most likely
implementation in general is "collect all the stats and filter out the
unwanted ones".

The chief scenario I want to avoid is:

- A adds experimental stat
- B notices the new stat, and starts grabbing it (without anyone noticing)
- A eliminates or changes the stat, so that it doesn't work for B any more
- B is upset enough to object
- A restores

we now have a stat that nobody intended to make permanent, but can't be
removed.

An explicit enabling of the experiment will:

- Make B "sign the contract" that they're accessing an experiment
- Give A a place they can instrument to figure out if anyone's doing it

I don't want to make a tool that serves too many purposes, it makes it
slippery in the hand.

>
> On Wed, Jan 4, 2017 at 1:16 AM Harald Alvestrand <harald@alvestrand.no
> <mailto: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?
>
>
>
>
>
>
>


-- 
Surveillance is pervasive. Go Dark.