Requests for comment/Json Config pages in wiki
Extension:JsonConfig is now live in production.
| Json Config pages in wiki | |
|---|---|
| Component | General |
| Creation date | |
| Author(s) | Yurik |
| Document status | implemented |
Status
edit- This extension has been implemented and deployed to production.
- All specifications has been moved from here to Extension:JsonConfig page.
Rationale
editThis extension offers an alternative way to store configuration data as JSON blobs in Wiki, as oppose to code files in GIT. This is not a proposal to abolish GIT storage, only an offer for an alternative data storage for cases when it makes more sense. So far I know that three teams, Logging, Zero, and UploadWizard have very successfully used this approach, e.g. m:Schema:Echo, m:Zero:250-99, and Commons Camgaign. Both have developed custom code to edit, validate, store, and visualize that data. Since Zero code was based on the event logging code, they both share that code which should be factored out. Here, I propose for the common aspects of that code to be extracted into a separate extension JsonConfig which would reduce duplication and allow other extensions to reuse it for their needs.
A typical file-based configuration workflow involves
- Editing in a text editor/IDE
- Git and Gerrit commands to submit that file for review
- Gerrit review with feedback, revisions, and finally +2
- Manual deployment steps such as ssh tin && git pull && sync-file
Replacing GIT with a wiki-based storage has a number of pros and some cons, and should not be done for all cases.
- Pros
- In-browser editing removes the need to do any git operations (everything from setup, cloning, and pulling to adding, committing, and submitting)
- Configuration is interactively validated by the same code that will use it later. There is no need to set up an independent Jenkins task.
- Configuration is easily accessible by PHP and JavaScript code without any additional steps, as well as through the MediaWiki API.
- Configuration can be visualized in a custom, extension-defined way
- Optionally, the review process could be done by the flagged revisions extension
- Configuration becomes active the moment it is saved / marked as reviewed
- Reverts in production are as fast as reverting a wiki page to an older revision
- A generic or a custom form-based editing interface would simplify some editing workflows
- Cons
- Edit linearity - GIT is much better suited for collaborative editing of the same file in exclusive fashion, and later merging it into a common master. Wiki page history is linear (although I heard of some proposals to change that). Since most changes in settings are fairly minor, I do not think this would be a significant problem.
- Gerrit offers a much better review system, with per-line and overall comments, multiple reviewers, better email notifications, -1s, etc. Wiki config only offers watchlist notification and a talk page, which might suffice for some, but not all cases.
- Most complex configs would be broken up into multiple wiki pages, making it harder to perform complex (e.g. regex) searches and would force one page at-a-time editing. This could be fairly easily solved with a simple script or a wiki mass editing tool such as AWB, but searching/editing multiple files is surely easier.