couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: CouchDB Plugins First Draft
Date Thu, 01 Nov 2012 10:17:05 GMT
there are also other plugins around : wich is using erlzmq


So on erlang the situation is quite complex. As a free reminder when we
spoke about rabbitmq plugins in january, nobody wanted that which let me
perplex. Like I said do we we want a plugin system or just a way to load

About couchdb-lucene for example it could be rewritten to use more of the
internals of couchdb. And probably using jinterface instead of living
externally so it could be better integrated.  (This is just an example of
what could be done) . couch_es could be fully written in elixir or js and
distributed as an internal couchapp. Same for random doc etc .

Imo when we speak about plugins we should have in mind the of their
deployement. This is one thing to install a plugin on a machine , another
to make sure that this plugin is installed on others machines. And when I
say other machines I'm not only speaking about machines in your lan (some
of us have tools and people for that) but machines of remote possibly
stranger people replicating your data . ANd this part is definitely not
possible easily with something like rabbitmq plugins.

- benoît

On Thu, Nov 1, 2012 at 11:01 AM, Bob Dionne <>wrote:

> Reminds me of my favorite book - "Sketches of an Elephant"
> Jan, thanks for putting a stake in the ground, I've wanted to see this
> forever. The proposal in my mind takes too much of a product management or
> marketing view (perhaps knowingly). Here's how it will look the buttons one
> will push, etc..
> I think the "what" and "how it works" are important to decide on first,
> .eg. @rnewson's suggestion for something like RabbitMQ. Reading the docs
> for that, the "what" is much clearer.
> Looking over the efforts to date, couchdb-lucene, and geocouch, these two
> are quite different in terms of design, one is roughly loosely coupled, the
> other more native (in the same VM). A plugin architecture, in my mind,
> should emerge from the code refactoring and layout we're currently
> discussing. We should ask and answer questions such as:
> 1. the role of externals
> 2 access to the storage layer (API?)
> 3. separation from http layer
> 4. support for code upgrades
> 5. balancing of resources
> I didn't mention Auth and Logging as I think these are separate in terms
> of concerns, more system oriented. Whereas geocouch and couchdb-lucene are
> actually extending the functionality in meaningful ways.
> On Nov 1, 2012, at 5:30 AM, Simon Metson <> wrote:
> > +1 - keep it simple for the first iteration.
> >
> >
> > On Wednesday, 31 October 2012 at 23:40, Robert Newson wrote:
> >
> >> I quite like the rabbitmq approach (a lot like the apache httpd
> approach).
> >> you can enable/disable/list plugins but the tool doesn't include the
> >> downloading and managed repository bits, which is a huge rabbit hole
> (pun
> >> intended).
> >
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message