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: <629F0E3A-6192-4555-90C9-379DA39E0161@dionne-associates.com>
Date: Thu, 1 Nov 2012 12:53:17 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C54715A1-E7B2-4FD2-B7C5-55E686086399@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>
To: dev@couchdb.apache.org


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

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

Totally knowingly, intentional even.

> 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

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 definitely want to stress that I=92d like to define the plugin feature =
from the user down, not from the technology up. This doesn=92t mean =
we=92ll 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=92s easier for the code we =
have today.


> We should ask and answer questions such as:
>=20
> 1. the role of externals
>=20
> 2 access to the storage layer (API?)
>=20
> 3. separation from http layer
>=20
> 4. support for code upgrades
>=20
> 5. balancing of resources
>=20
> 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.=20

Excellent observations and points!

Cheers
Jan
--=20

>=20
>=20
> On Nov 1, 2012, at 5:30 AM, Simon Metson <simon@cloudant.com> wrote:
>=20
>> +1 - keep it simple for the first iteration. =20
>>=20
>>=20
>> On Wednesday, 31 October 2012 at 23:40, Robert Newson wrote:
>>=20
>>> 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).
>>=20
>>=20
>>=20
>=20