[Concept] User-handled configuration scopes

[RainOrigami]

This is a discussion. Add arguments, ideas and examples to this discussion so that together we can make an informed and sound decision on whether or not, and how to implement such a concept.

Currently module configuration scopes (global, local) are defined by the module author because they know best what values can and can not be local or global.

Blu thinks this is not good and should be controlled by the user. I doubt this is a good idea.

Conceptionally a sound alternative to the current configuration handling has to be created that covers all existing cases and also allows for the additional case of letting users choose. It also can't be more complicated to use than the current system because some people already struggle finding the config files - making this more complex will only worsen this.

Requirements

Definite global variables

Variables that are declared global by the author and can not be made local by a user.

Cases for this include:

• Global timestamps for limiting
• Global caches

Definite local variables

Variables that are declared locally (per server) by the author and can not be made global by a user.

Cases for this include:

• Local timestamps for limiting
• Local caches

Dynamically scoped variables

Variables that do not have an explicitly defined scope by the author and can be made local or global.
Such variables should also be able to be declared globally and overwritten locally for specific servers.

Cases for this include:

• General settings that allow for local overwriting

[RainOrigami]

I argue against this for the following reasons

Complexity

Implementing such a system increases the complexity of the configuration file environment. The same values can now exist in multiple different scopes, adding to the confusion of the users.

This also requires additional documentation in the runner and modules to specify which variables are scopable and which aren't.

Jack of all trades

The runner shouldn't be a jack of all trades and cover each and every possibility. Instead it is made to be generic, so that additional functionality like this can be accomplished by the module author or user, if they so choose.

This would only cause feature creep where the issue can already be handled on an individual basis using the provided environment.

I argue for this for the following reasons

More customizability for the users

For cases where the user can decide on the scope of a configuration variable, it would be nice to have a way for them to choose and to overwrite global values for specific servers.