Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of antony.blakey@gmail.com
 designates 209.85.200.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=eAd+mLCRCC+BW/ny2S4i8NN0KbQA/gOyPKpnkI71dkA5V0r6LhVfMc7G1Jh0ZVBGvz
         On+2bNzMFj8Sb43CLrS2H9FwNh5dbLHsByZeZzlTQnU9Nc9LegfDBaIc2PNFpRqSg+Th
         MlBdtUcgENiDQjExqRqHuoOdmRuCThnXHhgiY=
Message-Id: <59071764-49FB-4EBE-A3D8-8C914DBD5F33@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: dev@couchdb.apache.org
In-Reply-To: <e282921e0902012306o28588ebeu6f6f926de2b16f2d@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Simple erlang plugins (was Re: couch_gen_btree: pluggable storage
  / tree engines)
Date: Mon, 2 Feb 2009 18:07:37 +1030
References: <498464EC.1070209@diskware.net>
 <e2111bbb0901311956x5040956elf76c3fe17e7526bd@mail.gmail.com>
 <8B1BF367-700E-4F24-B7A5-F454E51AF9D3@gmail.com>
 <e282921e0901312203q5ae4f67bla55ba8b72c2d78fe@mail.gmail.com>
 <8EED19F7-E294-4F3B-B260-09A46547C689@gmail.com>
 <E1F04CA8-5174-4234-8D04-58B22719F7B6@apache.org>
 <0E01B428-6C0E-480D-A8FB-0F8C45FD0CB2@gmail.com>
 <e282921e0902012216u4904be0an9e5eeaa5eb9a0e4@mail.gmail.com>
 <3F6DE847-1CF4-415D-8E60-F246FF8C9307@gmail.com>
 <e282921e0902012306o28588ebeu6f6f926de2b16f2d@mail.gmail.com>


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)