incubator-couchdb-user mailing list archives

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

An argument for #1 is that in uses cases like mine (millions of docs)
the presence of "extra" views can be a real headache. Users can just
provide the views necessary for the plugins to function. I like #1
also because it is "generative" as they say. By that I mean people can
come up for new and interesting ways to use the underlying feature (in
this case the ability to query couchdb from your plugin) that we can
never anticipate.

> 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.

There's currently the DbUpdateNotificationProcess, which I suppose is
another good candidate to be treated as a plugin.

I wish I had a deeper understanding of the Erlang internals (where it
would be convenient to draw the line between plugin and the code that
hosts it). I guess there is some common server interface we could
extract, and allow plugins to register for inclusion in. And then
there are private paths, both in the document-id namespace (eg
_design) and in the query-time url namespace (eg _view).

Some plugins will want to be passed all the documents in the database
(like views do, and the runners I describe in the wiki) and some
plugins will want to operate at query time (like search). Brad makes
the suggestion that some plugins may want to operate on the contents
of a map or reduce view.

Hopefully we can find a few more edge cases and out-there ideas so we
have a full picture before we try to cut it down to just the
essentials and start writing code.

Chris Anderson

View raw message