Spongeapi: API for plugins to consult if stats collection is enabled

[mbax]

Passes plugin to the method, so Sponge can include each plugin separately in the config (updating as it gets new plugins), for per-plugin as well as global settings.

Code possible suggestions:

Sponge.getStatsManager().isStatsEnabled(plugin);
Sponge.getPluginManager().isStatsEnabled(plugin);
Sponge.getPluginManager().getStats().isEnabled(plugin);

Example usage

if (Sponge.getPluginManager().isStatsEnabled(this)) {
    Metrics metrics = new Metrics();
    // Stuff here
}

Config examples:

{
  "stats": {
    "global-status": "disable",
    "per-plugin-enable": {
      "craftirc": false,
      "specatastic": false
    }
  }
}

{
  "stats": {
    "global-status": "enable",
    "per-plugin-enable": {
      "craftirc": false,
      "specatastic": false
    }
  }
}

{
  "stats": {
    "global-status": "per-plugin",
    "per-plugin-enable": {
      "craftirc": true,
      "spectastic": false
    }
  }
}

Other thoughts

• Plugin devs will want a way to allow easy enabling
  
  
  
  • Proposal: General Sponge command. /sponge stats <enable/disable> <plugin>
  
  
  • This way, plugins could say (once, preferably) "Please consider enabling stats, run /sponge stats enable craftirc"
  
  
• There has been discussion of making a full stats service API. This could be part one of that.

[ST-DDT]

Does this stats API refer to a MCStats.org like stats service/feature?

(Would it be SpongePowered? Is it possible to help developing it?)

[Yeregorix]

I don't think Sponge must be responsible of the configurations. I would let this for the different stats collection systems as long as they follow our minimum requirements. Because, otherwise they might still use their own config files, even if Sponge has already one, to have different options and users will be lost between the different files.

[liach]

FYI this feature is mainly added for ore. The major issue with the feature is that it is almost completely useless outside of the ore environment.

[Yeregorix]

This does not seem to be a problem. If you don't want to use it then don't use it. You will just be rejected from Ore which is okay if you don't want to post your plugin on Ore.

[mbax]

@ST-DDT This is based on discussion of how to better enable server operators to control which of their plugins send stats data to external services (mcstats, bstats, etc.). At present there is no plan for Sponge to operate our own stats service. Though it would be awesome, we don't presently have the resources (in particular our web-based dev resources are pointed strongly at Ore right now).

@Yeregorix Here's a neat fact from the survey we ran. While 35% of responding operators would enable stats collection if disabled by default in individual plugins, 60% of responding operators would take advantage of a centralized config to either enable (20%) or selectively enable (40%) stats collection (and 30% would immediately fully disable while 10% would ignore the feature). It looks like a centralized system would actually benefit plugin devs who like collecting data on their users.

@liach With Ore being the intended central source of plugins, I'm not too concerned about it not being useful outside that. :)

[liach]

liach - Today at 12:23 PM
@mbaxter if that becomes a config, in china or places where people do not grab from ore (or for premium plugins), server owners might think this config option to disable stats work but it actually doesn't.

With Ore being the intended central source of plugins

This is not quite the case. Ore places many restrictions on the plugins, one of them is that plugins must be free. Of course, there are premium plugins in sponge as in spigot. If one such stat manager exists, we need to figure out a way to make premium plugins respect this rule.

A better solution is to let spongepowered (?!) host a stats collection site and offer the stats access in the api. Meanwhile, we can wrap the stats access in the suggested stats manager in order to grant users better controls over the stats of sponge plugins, etc.

[liach]

Since the official stance of sponge is that sponge cannot afford another stats site, sponge might consider adding bstats, etc. natively and control their usage through the newly added hook.

[gabizou]

Since the official stance of sponge is that sponge cannot afford another stats site, sponge might consider adding bstats, etc. natively and control their usage through the newly added hook.

Yeah no. Not depending on yet another third party library that is going to get outdated and bug fix maintained poorly like Timings has already been done with sponge.

This is not quite the case. Ore places many restrictions on the plugins, one of them is that plugins must be free. Of course, there are premium plugins in sponge as in spigot. If one such stat manager exists, we need to figure out a way to make premium plugins respect this rule.

Since when has this been a conversation about plugins distributed outside of Ore? Premium plugins not respecting the rule is not our job, let alone a worry for us as the server administrator has, at that point, accepted literally all responsibility by paying for a plugin from a third party from a third party distribution system (media fire, forum pm's, whatever). Why would we say "oh, let's cow tow to centralizing stats collection and raise awareness for premium plugins of which we have no presence or validation from us as an organization." The answer is, we won't. I don't care what the use case to make a plugin premium, Ore is just a standardized central repository that is maintained, cultivated, and managed by the organization. We're not policing things that we have literally no control over.

To put my heavily biased opinion, I'm voting to provide the simple config check where there's the following:
Sponge.getStatsConfig().areStatsEnabled() and Sponge.getStatsConfig().areStatsEnabled(PluginContainer) or (object) depending on how you want to write it.

As far as validating that a plugin is not obeying stats config is to be policed by the community if it is not distributed through Ore. It's that simple.

[liach]

Agree. I would support a simple approach like this given the authority of ore once it is published.

[ST-DDT]

Please let me confirm whether I got it right.

Statistics-Website:

• wont be created (for now due to a lack of development resources)

Statistics-API/Servive:

• will not use a ThirdParty impl to avoid it becoming outdated
• has no own impl so there need for it yet

Statistic-Config:

• yes, plugins that send stats must check it before sending stats (if they want to be on Ore).

[dualspiral]

Yes, all this proposes is that we expose whether a server admin has given permission for metrics collection, either globally or on a per-plugin basis via some config option. It does not provide a service for stats plugins to implement (like economy or permissions) and does not perform any data collection itself. It is purely a central way to determine if a server owner has given permission for these activities.

[Yeregorix]

Here is a config example that looks slightly simpler and clearer IMO:

{
    "stats": {
        # Determines whether a plugin that is not yet on the list below should be enabled or disabled when added to the list.
        "enabled-by-default": false,
        # Determines which plugins have statistics collection enabled or disabled.
        "plugins": {
            "craftirc": true,
            "spectastic": false
        }
    }
}

[mbax]

Maybe an additional comment there saying you can wipe the plugins section entirely to reset all plugins to the new default state.

[FerusGrim]

I like the idea of having a simple, global configuration for this.

[dualspiral]

Oh, I had something for this, but didn't end up pushing it. Let me put it up quickly, I'll set up the PR in a bit, then a discussion can occur. I'm sure it'll need to be tweaked.

Note it's based on a simple config check that auto-populates plugins. It's not an intercepting check, if that's what we really want, then we'll need a different approach.

[dualspiral]

I've opened PRs for SA/SC/SF. SV needs a one line change akin to SF, but I'll do that when I have a bit more time/discussion.