On 01/02/2009, at 2:26 PM, Paul Davis wrote:

> Very cool ideas. We've been discussing erlang plugins. The
> conversation has generally gotten as far as, "erlang plugins... yeah
> we should have those."

The mechanical side of building and deploying standalone erlang  
plugins that extend couch, including extending the configuration  
locations, is very simple, roughly equivalent to the classpath/ 
load_path issues in e.g. java/ruby, modulo the issue of config-file  
writeback from within CouchDB. I've done and deployed this, although  
the appropriate 'hooks' aren't always available, which I guess is the  
essence of the OP plugin system.

I've built external indexers using both this mechanism, and _external,  
as have others (GeoCouch, FTI). At one stage I was able to execute SQL  
queries against Couch data that was replicated into SQLite databases,  
but I decided not to maintain it. As long as your indexer architecture  
acknowledges the fundamental Couch model, and is prepared to do a full  
regeneration at any time, you can replicate the operational semantics  
of inbuilt views quite easily and with high performance (e.g. no per- 
request hit to Couch). There are a few edge cases, namely purging and  
db re-creation that need a small mod to the core to allow 100% correct  
plugins.

My $0.02 ... I think the existing build system would benefit from a  
more modular approach because it would reify the coupling between, and  
layering of, existing features e.g. the upcoming stats module would  
consist of a capture core and an analysis/access plugin.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Human beings, who are almost unique in having the ability to learn  
from the experience of others, are also remarkable for their apparent  
disinclination to do so.
   -- Douglas Adams