Configurable plugin loading?

[tbielawa]

Kel's AWS metadata plugin made me think of this:

I can see circumstances where an organization/user may not wish to load and expose all of the default plugins. It might be worth considering ways to configure exactly which plugins are exposed.

Things to think about that I've seen in other projects:

• Whitelist
• Blacklist
• Matching (glob/regex) support

[kelcecil]

I think it's worth taking a few steps back and considering the plugin system further. There's a lot of cool stuff you can do here. Not sure if the following is relevant to your post above, but it's food for thought.

There's also situations where you could make plugins that are generic. I was thinking that an uptime plugin would be cool. Everyone loves knowing server up time. It's a cool thing to include, but it seems silly to write a plugin just to return uptime. It makes more sense to have a generic shell plugin that could just run what you'd like. I could configure it like this:

{
    .... config stuff here ...
    "plugins": [
                    { "key": "uptime",    // key of the json that comes back
                      "plugin": "shell",     // plugin name, runs a shell command in this case
                      "options": { "command": "uptime" }    //  You could pass this options as a dict right to the plugin.
                    } 
    ]
    ... potentially more config stuff here ....
}

Couple this with your argument reloading, and you could just new items to your feed on the fly. Pretty endless possibilities there.

[tbielawa]

@kelcecil At first read I thought you were suggesting a plugin that lets you call arbitrary commands during runtime, like

$ curl http://foo.com/jsonstats/plugins/cmd?command=rm%20-fR

But that would be silly!

I like your idea. Lets create an RFE for that in the next enhancement release, the milestone is called jsonstats-1.0.4