couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brad Schick <>
Subject Re: gathering requirements for the plugin system
Date Thu, 19 Jun 2008 07:05:05 GMT
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:
> 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.


View raw message