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: 
 <CABvT1DFc6p0mNOdUFr-aRakEaX8CZYE7_M_rx2uCc14Em+7+PQ@mail.gmail.com>
Date: Thu, 1 Nov 2012 13:08:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <015D1FF2-1242-491C-AC74-EEECB64C310E@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>
 <CABvT1DFc6p0mNOdUFr-aRakEaX8CZYE7_M_rx2uCc14Em+7+PQ@mail.gmail.com>
To: dev@couchdb.apache.org


On Nov 1, 2012, at 12:57 , Robert Newson <rnewson@apache.org> wrote:

> couchdb-lucene already "plugs in" to couchdb in a pretty reasonable =
way, so
> I don't think it illuminates this discussion. It will always require =
an
> external process (the JVM). It's hard to see how a plugin system could =
be
> so generic as to support every possible kind of plugin. I quite like =
the
> rabbitmq one that insists that each plugin is OTP-shaped, and stopping =
at
> that point.

Cool, thanks. I think a =93native plugins only=94 first step would be a =
great
thing to ship. Discussion of =93external plugins=94 can happen after =
that. I=92ll
make a note about priorities in my document.


> Apart from that observation, I don't have much to add. I've not
> suffered from the lack of "plugin support" and will be no richer for =
it
> when it lands.

You=92ll be surprised what cool things are going to happen :)

My motivation for this is clearing out all these branches all of us
have with features that are quite nice, but not really applicable to
everybody, or not feasible to carry around in core.

I also hope that this leads to more experimental features on top
of CouchDB that solve a number of people=92s problem. Things like
a transactional _bulk_docs plugin for people the want that and
understand the trade-offs (look at me opening a particularly
big can of worms).

I=92d like a future where we have a solution for developer=92s problems
rather than telling them to rethink their problem-space like we do
now. A plugin system allows us to do that without compromising the
integrity of core Apache CouchDB, while making our technology more
applicable to a wider range of users.

Finally, I think that we can use this mechanism to move some
features out of what is currently core (discussion TBD for when we=20
*do have* plugins, please don=92t jump onto that particular point now,
thanks :) and make for a leaner code base all around.

* * *

I=92m happy to concede that you don=92t agree with this future, I=92m =
just
sharing my unbounded excitement for this :)

Cheers
Jan
--=20


>=20
> On 1 November 2012 11:53, 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
>>> 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.
>>=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 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.
>>=20
>>=20
>>> 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!
>>=20
>> 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
>>>> 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
>>=20
>>=20