couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Dionne <dio...@dionne-associates.com>
Subject Re: CouchDB Plugins First Draft
Date Thu, 01 Nov 2012 15:53:05 GMT

On Nov 1, 2012, at 7:53 AM, Jan Lehnardt <jan@apache.org> wrote:

> 
> On Nov 1, 2012, at 11:01 , 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..
> 
> Totally knowingly, intentional even.

in that case, good luck, that's a long expensive haul.

> 
>> 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.

> 
> This seems contradictory to your previous statement

> My document started the "what" and "how it works" discussion just fine. Whatever is unclear
needs to be resolved *before* we jump into any implementation.
> 
> 
>> 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).
> 
> Yup, we need to define how this fits into the plugin system. Maybe we never to something
like couchdb-lucene, maybe we do native plugins first, and external plugins later, or the
other way around. Thanks for making this more explicit, I will add this to the document.
> 
> 
>> A plugin architecture, in my mind, should emerge from the code refactoring and layout
we're currently discussing.
> 
> I respectfully disagree. I would like to start from the user and work my way down. What
ever internal refactorings make sense to support the use-case, we will have to make. I trust
that we are smart enough to make this in a way that is favourable to the rest of the code
base.

I see, great. I think we have perhaps different interpretations of "user". Given the current
state of the code base I see the users as programmers trying to extend the existing code in
interesting ways. An architecture for plugins that emerges bottoms up from those attempts,
similar to how the couch_api_wrap and couch_index refactoring came about, is what I'm interested
in. Top down high level approaches rarely work in practice *except* where there are lots of
resources and control over the process, both of which are in short supply in open source efforts.

YMMV,

Bob


> 
> I definitely want to stress that I’d like to define the plugin feature from the user
down, not from the technology up. This doesn’t mean we’ll bend over backwards to accommodate
some crazy concept we draw up, but I think it helps keeping in mind who we do this for is
great for making informed decisions rather than what’s easier for the code we have toda


> 
> 
>> 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. 
> 
> Excellent observations and points!
> 
> Cheers
> Jan
> -- 
> 
>> 
>> 
>> 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