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
