On 02/02/2009, at 5:36 PM, Chris Anderson wrote:
Maybe each plugin could have a default.ini and a local.ini, so
something like:
plugins/
geo_index/
Makefile.am.in
src/
geo_index.erl
geo_httpd.erl
geo_manager.erl
default.ini
local.ini
...
Then CouchDB could automatically pickup plugin config from each
directory, running all the defaults before all the locals.
I think we may be talking at cross-purposes here - I'm thinking
particularly of plugins that are separately compiled without being
included in the canonical sources, while I gather you're focussed on a
refactored core or a way to handle less tightly coupled contributions.
I'm interested in seeing those things happen, but I'll be guided by
you as to what I should for that. In particular I know sfa about
automake et al.
OTOH, I think top level default.ini + local.ini + local.*.ini would be
a good idea regardless, and a simple change.
I'm not invested in these specifics, just trying to think of ways it
could look that would give new developers the least amount of
head-scratching.
I think head-scratching would be best mitigated by some good docs. If
we want to implement this then I'll commit to writing a spec/tutorial
on the wiki.
My concern is how to allow plugins to be updated without stomping on
user configuration, which is why I suggest having the local plugin
configuration be outside of the plugin's directory. Maybe that's a
deployment required that's unlike to happen, but I look forward to a
time when couch plugins are like rubygems and regular updating is
common.
Somewhat OT: plugins are also a mechanism for deploying generic non-
couch functionality for a deployment scenario like mine where every
user runs a Couch instance ala Notes client e.g. distributed voting
algorithms and scalaris-like functionality for emergent clusters
within wider p2p meshes.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Plurality is not to be assumed without necessity
-- William of Ockham (ca. 1285-1349)
