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
