Requests for comment/Json Config pages in wiki

Many extension require fairly complex configurations. So far I know that two teams - Zero and Logging - very successfully used the approach of storing JSON blobs as wikitext on Meta, e.g. m:Zero:250-99 and m:Schema:Echo. Both have developed custom code to edit, validate, store, and visualize that data, yet they both share lots of common code (Zero code was actually based on event logging code, but they have since diverged).

I propose for the common aspects of that code to be extracted into a separate extension JsonConfig, designed in a way to be useful not just to Zero & logging, but to allow a very easy way for any extension to store its own configuration.

Implemented Features
These features have already been implemented in Zero and/or logging, and might be useful for other extensions:
 * Visualization shows JSON as an easy to view table rather than code, with some extra highlighting. For example if the value is not provided and a default is used, it is shown in gray, or when the value is the same as default, it shows as purple. For example, see this and this.
 * Code Editor simplifies JSON editing
 * Custom Validation performs complex checks such as checking that the value is in the proper format or that a user ID exists.
 * MemCached caching stores json blobs in memcached under custom keys and expiration policies, and resets them on save.
 * Flagged Revisions support allows configurations to be marked as "reviewed" before going into production
 * Localization of most basic interface elements has been done in many languages, and it would reduce translation work if most common messages would be done just once in one place.

Unimplemented Nice-To-Haves
These features would be desirable to more than one type of configs:
 * Schema validator - Validate against JSON Schema, as most extensions might not need complex validation rules, or might want to combine schema plus extra validation.
 * Custom editor - Zero team has been thinking about implementing a more complex editor, possibly based on JSON Schema.
 * API query support - Allow config pages to be returned as regular API results in all formats - json/xml/... instead of text blobs:
 * api.php ? action=query & titles=Config:Proxy:Opera & prop=jsonconfig
 * Localization - it would be good to be able to show localized descriptions for each configuration key

General Usage
Lets say we decide to store the IPs of all legitimate proxies, whose X-Forwarded-For header can be trusted.

In this case Opera-Mini server info would be stored as a page named Config:Proxy:Opera. This naming scheme allows us not to pollute namespaces (which many users have objected, probably due to how advanced search looks, and how the list of namespaces is shown in all the special pages with filters). JsonConfig will handle all pages in Config namespace, and each extension would specify its own prefix, e.g. "Proxy".

Sample page content:

Configuration
Extensions that use config extension may choose several usage patterns:

Single page free-form configuration in the default namespace allows users to create just one page called Config:MyExtSettings. As long as the page is a non-empty JSON object, it will be accepted.

If your extension needs multiple similar settings pages, a sub-namespace can be used. This configuration allows any pages named Config:MyExt:...:

For some cases, an extension may choose to have its own top namespace instead of using a sub-namespace. Here we create namespace called Zero:... and Zero praise:...:

Of course at a certain point you would want a custom content class with its own defaults, validation, and HTML rendering. To set it up, specify a model ID and a class that derives from the \JsonConfig\JCValidatedContent:

$wgJsonConfigEnableHosting
This variable (false by default), enables storage of the configs on the current wiki. Keeping it as false is useful when this wiki will only use config values from another wiki, not actually store them locally.

$wgJsonConfigs
This variable defines which pages are treated as configuration pages. $wgJsonConfigs is an indexed array of arrays, with each sub-array having zero or more of the following parameters.

$wgJsonConfigModels
This variable defines which custom content class will handle which Model ID. More than one Model ID may be handled by the same content class. All content classes must derive from \JsonConfig\JCContent class. If the modelID is mapped to null, the default JCContent class will be used.

Example:

Implementation details
JsonConfig is implemented as two parts - storage/parsing and editing/visualizing. The editor/visualizer is only available when JsonConfig runs on meta wiki, and allows complex presentation of the Config namespace wiki pages. The storage/parsing is available on all wikis, allowing quick access to cache as well as validation and parsing of the cached json blob.