Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\))
Subject: Re: CouchDB Plugins First Draft
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: <0DB0D7B5-7F5E-498C-AC37-A55153465DDD@dionne-associates.com>
Date: Thu, 1 Nov 2012 17:03:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <11B8BC8E-4475-477F-B924-B4114B5C33B9@apache.org>
References: <40BCC84F-C695-492E-B56E-08C60955A3D8@apache.org>
 <CAHdjipK3UOg3FbnA_sGUpcP8YXOa0PYfnn3Zx0JmTodPjJdu+A@mail.gmail.com>
 <CABvT1DFAcMQtx4WGBPwZwqRkNzVBFPCnFb_djirDtS_9RFJsFw@mail.gmail.com>
 <3B2D6B8E471743B49554B23F98B8414C@cloudant.com>
 <629F0E3A-6192-4555-90C9-379DA39E0161@dionne-associates.com>
 <C54715A1-E7B2-4FD2-B7C5-55E686086399@apache.org>
 <0DB0D7B5-7F5E-498C-AC37-A55153465DDD@dionne-associates.com>
To: dev@couchdb.apache.org


On Nov 1, 2012, at 16:53 , Bob Dionne <dionne@dionne-associates.com> =
wrote:

>=20
> On Nov 1, 2012, at 7:53 AM, Jan Lehnardt <jan@apache.org> wrote:
>=20
>>=20
>> On Nov 1, 2012, at 11:01 , Bob Dionne <dionne@dionne-associates.com> =
wrote:
>>=20
>>> Reminds me of my favorite book - "Sketches of an Elephant"
>>>=20
>>> 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..
>>=20
>> Totally knowingly, intentional even.
>=20
> in that case, good luck, that's a long expensive haul.
>=20
>>=20
>>> 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.=20
>>=20
>> This seems contradictory to your previous statement
>=20
>> 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.
>>=20
>>=20
>>> 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).
>>=20
>> 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.
>>=20
>>=20
>>> A plugin architecture, in my mind, should emerge from the code =
refactoring and layout we're currently discussing.
>>=20
>> 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.
>=20
> 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.

Yup, different POV, my users are people who program against CouchDB that =
might want additional features that aren=92t in core CouchDB. There are =
also plugin authors to which we need to cater, and the things you bring =
up definitely fall in that bucket. I just want to start things out from =
the end-user, that is all. We are on the same page.

Cheers
Jan
--=20