On Thu, Jun 19, 2008 at 12:05 AM, Brad Schick <[EMAIL PROTECTED]> 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 http://jchris.mfdz.com
