incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: CouchDB Plugins First Draft
Date Thu, 01 Nov 2012 11:57:16 GMT
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. 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.


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 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.
>
> 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’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 today.
>
>
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message