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.
 * Custom API allows all mobile zero users to load the appropriate slimmed-down configuration based on request's header, or netmapper to wget the list of all IPs configured as part of the Zero configurations.
 * 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
The Proxy extension needs to configure JsonConfig with prefix and any custom validation code. I am really not sure about this section just yet, but here are some of my thougths. ProxyExt is the namespace of the proxies extension.

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.

Due to this ui/usage need of the config object, I can see two implementation paths:
 * Derive Config from TextContent
 * Pros: A TextContent-derived object is needed for the UI
 * Cons: Possibly high overhead(?) for non-UI usage, as the object will need to be deserialized from storage


 * Standalone object
 * Pros: Full control over object's lifecycle and performance
 * Cons: A generic TextContent wrapper is needed to handle prefix-specific config object instantiation