Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: <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>
	<015D1FF2-1242-491C-AC74-EEECB64C310E@apache.org>
Date: Sat, 3 Nov 2012 16:47:58 +0000
Message-ID: 
 <CAPaJBx6WkTxgu1KZVQqXYAG2=JVVXGom-TQia5WDbjpqfdeVbw@mail.gmail.com>
Subject: Re: CouchDB Plugins First Draft
From: Noah Slater <nslater@apache.org>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=047d7b2e135bbc2bfe04cd9a03da

--047d7b2e135bbc2bfe04cd9a03da
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

This is a great initiative. Thanks for leading the charge, Jan!

I am personally very excited about the future of CouchDB with a lean core
and a vibrant plugin system.


On 1 November 2012 12:08, Jan Lehnardt <jan@apache.org> wrote:

>
> 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 th=
e
> > 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 g=
reat
> 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
> *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 jus=
t
> sharing my unbounded excitement for this :)
>
> Cheers
> Jan
> --
>
>
>
>
>
> >
> > On 1 November 2012 11:53, 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 thi=
s
> >> forever. The proposal in my mind takes too much of a product managemen=
t
> or
> >> marketing view (perhaps knowingly). Here's how it will look the button=
s
> one
> >> will push, etc..
> >>
> >> Totally knowingly, intentional even.
> >>
> >>> I think the "what" and "how it works" are important to decide on firs=
t,
> >> .eg. @rnewson's suggestion for something like RabbitMQ. Reading the do=
cs
> >> for that, the "what" is much clearer.
> >>
> >> This seems contradictory to your previous statement. My document start=
ed
> >> the "what" and "how it works" discussion just fine. Whatever is unclea=
r
> >> 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 ma=
ke
> >> 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 featu=
re
> >> 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 to=
day.
> >>
> >>
> >>> 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 th=
e
> >>>>> downloading and managed repository bits, which is a huge rabbit hol=
e
> >> (pun
> >>>>> intended).
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
>
>


--=20
NS

--047d7b2e135bbc2bfe04cd9a03da--