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