1.1 Config in the Database

[rossjones]

As a Developer I want to set config from a web API so that I can change
these settings from my program (or from a UI that uses AJAX)

Implementing this will likely involve following pieces of work

    1. Moving most configuration to be in Database (in a new table) and 
        making relevant changes to the app in light of this (e.g. so that app 
        loads config from the DB)
            a. Ensuring that changes in config result in a reload of this config
                in the app (e.g. by changing app to load DB config on every request)
    2. Maintaining backwards compatibility by still loading config from disk
        for cases where some or all of config is still on disk (so search disk first, 
        then load DB config - DB config overwrites disk config)
    3. Create a Web UI as part of CKAN Admin Dashboard for viewing and 
        updating config (e.g. located at ckan-admin/config)

[rossjones]

Moving config to the database has been discussed a little before at https://github.com/ckan/ideas-and-roadmap/issues/88

At the most extreme this could involve the postgres url being in an Operating System environment variable (or determined from the ones Postgres already understands) and everything else being in the database - but there are likely to be issues when extensions want their own configuration options.

Moving the .ini values to the database 'as-is', a collection of lines with just string values seems most straightforward, but there may potentially be more value in understanding what the values are and grouping them accordingly. All the solr options together under one heading for instance.

Handling extension configuration options beyond simple map of the .ini format wouldn't really be feasible immediately (unless the plugin itself decided to offer a WUI for it) but could still be done under a heading per extension, or perhaps a section at the end for free-form configuration options.

I'm not sure how feasible the reload on every request is, it would require passing the update configuration information to the plugins that have registered as wanting to modify/update config, and all plugins would have to be reloaded as it isn't known if they read config at any point during their processing. I'd suggest this should be a wider descriptions 'Updates to config should be available relatively shortly after the update, and the plugins may need to be reloaded', so that whoever does the work has the flexibility to implement it as they see fit.

This could probably all be done as a single piece of work.

[jqnatividad]

Also, how would this impact installing plugins/extensions? If we are to cf Wordpress dashboard as per the draft proposal, WP exposes a way to install extensions via the web interface as well.

[rossjones]

I added https://github.com/ckan/ideas-and-roadmap/issues/113 today because it's been bugging me for a while :) Even better if it could be hooked into http://extensions.ckan.org

[jqnatividad]

+1 on hooking up to extensions.ckan.org. Already, there are 275+ CKAN extensions (https://github.com/ckan/extensions.ckan.org), of which 99 are listed on the site.

Hooking up the registry will go a long way towards expanding the CKAN extension development community, and follows the WP plugin registry example, with its 34,000+ plugins.