Talk:Requests for comment/Json Config pages in wiki

Begging the question

Personally, I'm not entirely convinced that shoving blobs of json in wiki pages for configuration is all that great of an idea in the first place. For developers it makes sense (although then there's the question of why developers need to configure things by editing a json blob in a wiki page), but does requiring end users to be able to construct a valid json blob in order to configure some feature really make sense? Anomie (talk) 14:41, 4 December 2013 (UTC)

At least two (that i know of) implementations of this exact feature shows that it is needed - there are cases when devs (or techy people) need to easily edit fairly complex configurations, while having access to all the wonderful wiki benefits (listed on the page). Secondly, this extension exists specifically so that it would be possible to construct a json-editing as a form feature in one spot and benefit everyone. --Yurik (talk) 02:58, 17 December 2013 (UTC)

Or it shows that two projects used Maslow's hammer. I'm not seeing a list of "wiki benefits" in the page either; I do see a list of "Implemented Features", most of which seem like working around wiki drawbacks versus storing server configuration in the server configuration and using Gerrit for code review. Anomie (talk) 14:11, 17 December 2013 (UTC)

Funny, because I think using LocalSettings or huge Yaml/XML config files stored in git, with very complex QA tools that frequently break and few know how to configure (jenkins) to do validation is a much better example of such hammer (source code control with files) with a huge number of workarounds. The number of steps required to meaningfully change configuration is humongous - git pull, edit file, save, git add, git commit, git review, gerrit +2, ssh tin, git pull (oops, git fetch & compare and visually inspect), sync-file... I hope I didn't break production in the process... And these steps differ depending on which system you are configuring, and the only validation steps involved here are jenkins and manual review.

Wiki is similar to git (versioned storage), but it offers us a way to significantly shorten these steps for SOME use cases (this is not a magic hammer after all, just a tool that fixes some use cases conveniently). I think instead of fighting this change, we should look at which problems it solves, and make it solve them well, while keeping traditional .conf file approach where it's more appropriate.

The benefits, and I will think of what to put on the page, are: quick editing, complex custom validation, flagged-revs -based approval system, custom visualization. Other than gerrit that has fairly good per-line comment review system (here - flagged-revs), other systems are severely lacking (speed, convenience) or nonexistent (custom rendering). --Yurik (talk) 11:24, 18 December 2013 (UTC)

I updated Rationale section to better state my intent. This RFC is not proposing to blindly replace all setting files with a wiki storage. It offers an alternative for those usecases which would actually benefit from it. --Yurik (talk) 00:52, 24 December 2013 (UTC)

Developer API

I would like to see some interface how developers could fetch and update configs. Also a concrete example (doesn't need to be functional) which implements things like validation would help.--Nikerabbit (talk) 11:56, 17 December 2013 (UTC)

Posted some examples of the config fetching (most of the code is finished - alpha stage). Updating config obviously could be done via code (similar to how we script page editing in tests), but that's outside of the scope here - as it will be mostly done via wiki editing. --Yurik (talk) 11:27, 18 December 2013 (UTC)

This is a good idea and should get more attention

This seems like a very important step forward in usability for MediaWiki on third party installs, especially wikifarms and wikis run by community members who are not given FTP access. A key step forward against spam on smaller wikis could come from this if the ability to edit&view specific config pages is made granular enough, since normal trusted users could create an endless supply of new capatcha questions without giving them FTP access (some view controls needed to stop spambots reading off the answers, and preferably granular controls to allow editors to be given just a 'capachaedit' right). Once this is mature and many common extensions support the format I would love to see it bundled with MW. Edit: Looking over other RfCs, looks like this is a much better fit.--etesp (talk) 21:55, 30 April 2014 (UTC)