Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of schickb@gmail.com designates
 209.85.200.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=tQ+OEl5LzVUMbX8f4VA0ckmHS1ZbCGw6J2d1lxsK/unubqg434HDyz3T8nZSOobGMF
         5KWG+pQ/C7w05+Az8gmTjhnS4i9kMFFlURJiYBgfxUmYHUHJ6oXzxaWaEGRUtBlyHi0I
         hG4rAnLI6k4x1X2XBOiMkt5+SCx25jItBqAHE=
Message-ID: <485A0521.5070303@gmail.com>
Date: Thu, 19 Jun 2008 00:05:05 -0700
From: Brad Schick <schickb@gmail.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: couchdb-user@incubator.apache.org
Subject: Re: gathering requirements for the plugin system
References: <e282921e0806182125w2ec9cd37i998efbff014e585b@mail.gmail.com>
In-Reply-To: <e282921e0806182125w2ec9cd37i998efbff014e585b@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 6/18/2008 9:25 PM, Chris Anderson wrote:
> We've been talking a little in the IRC channel about the plugin
> system. It doesn't exist yet, so we're trying to figure out what use
> cases it needs to support. I've started a wiki page to gather ideas,
> and please also discuss things here. Anything you'd like to do with
> CouchDB that isn't really part of its core functionality, could be
> supported in a plugin. Also, some of the core features will be
> supported by the plugin system as well (as far as I have gathered from
> the IRC discussions). These include the view servers and the search
> servers.
>
> The wiki page: http://wiki.apache.org/couchdb/PluginAPIUseCases
>
> The goal is to have the foundation for plugins ready for the 1.0
> release (I think, based on the IRC discussions.)
>
>   
Sounds like a good idea. Is there a plan for selecting the documents 
that a plugins will operation on? Some plugins might want to handle that 
entirely on their own (via custom query parameters), but for many 
plugins it would probably be helpful if Couchdb handled most of the 
details. Two ways to select documents come to mind.

1) Provide a way for plugins to install and access standard views.
2) Let each plugin instance provide a map (and perhaps reduce) function 
for itself.

I like #2 better because the "view" would be directly attached to the 
plugin rather than being independent. In my experience invisible 
dependencies lead to problems. But with either solution callers should 
be able to use the standard view like query options; key, startkey, 
endkey, count, etc.

Another thought: If plugins want to maintain state that depends on 
couchdb documents, won't they need a notification facility? Filtering 
these notifications would be another good use of map (and perhaps 
reduce) functions associated directly with plugins.

-Brad