On 12/15/09 1:29 AM, Jan H Wildeboer wrote:
Objection :-)

Coming from an ISP perspective and now at Red Hat managing big
companies, I have come to love config files. When deploying in an
automated way, it is trivial to deploy config files that are templated.

The more config is in the database, the more complicated automated
deployment gets.

So if config.php.sample is removed (or reduced to DB connection info), I
would definitely want to see a little script that takes a .sql file with
all config info and puts in the db.

To clarify -- you'll still be able to do configuration through config.php, we're just dropping the manually-maintained list of sample option lines.

What I'd actually like to do is to improve our auto-generated documentation; we'e got doxygen-style doc comments scattered throughout on many (but not all) classes and functions but could benefit a lot from similar doc markup for configuration options.

Comments right in the code are more likely to be kept up to date as the code changes, and we can build a nice complete, up to date list of available options for our documentation.

Maybe something like this...?

Core options in default.php:

        'throttle' =>
        array(
              /**
               * @config Whether to throttle edits
               */
              'enabled' => false,
              /**
               * @config Number of allowed messages in timespan
               */
              'count' => 20,
              /**
               * @config Timespan for throttling, in seconds
               */
              'timespan' => 600),


Plugin options:

class MeteorPlugin extends RealtimePlugin
{
    /**
     * @config Web server address.
     * @default site server
     * @example 'realtime.example.com'
     */
    public $webserver = null;

    /**
     * @config Port to connect to for Web access.
     * @example 8080
     */
    public $webport = 4670;

In many cases a default and data type can be extracted straight from the source; in others we may need to specify or give examples if it's unclear or starts as null to be auto-filled from some other info.

Knowing the config section or plugin name, the documentation tool could easily build sample config lines like:

  addPlugin('MeteorPlugin',
            array('websevrer' => 'realtime.example.com'));

from that which could be cut-n-pasted from documentation into a config file.

-- brion vibber (brion @ status.net)
_______________________________________________
StatusNet-dev mailing list
StatusNet-dev@lists.status.net
http://lists.status.net/mailman/listinfo/statusnet-dev

Reply via email to