incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: CouchDB Plugins First Draft
Date Thu, 01 Nov 2012 11:59:09 GMT
Benoit,

Thanks a lot!

You bring up a lot of great material to the discussion along with your
expertise in writing and handling plugins in rcouch and related projects.

I’ll comb through this thread and extract all relevant information into
the gist/wiki document.

This is all great stuff! :)

Jan
-- 



On Nov 1, 2012, at 11:17 , Benoit Chesneau <bchesneau@gmail.com> wrote:

> there are also other plugins around :
> 
> https://github.com/benoitc/couch_randomdoc
> 
> https://github.com/benoitc/couch_zmq wich is using erlzmq
> 
> https://github.com/benoitc/couch_es
> 
> https://github.com/refuge/bigcouch_spatial
> 
> https://github.com/refuge/couch_dbupdates
> 
> https://github.com/ocastalabs/CouchDB-XO_Auth
> 
> ....
> 
> 
> 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
> app?
> 
> 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 <dionne@dionne-associates.com>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 <simon@cloudant.com> 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).
>>> 
>>> 
>>> 
>> 
>> 


Mime
View raw message