incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: CouchDB Plugins First Draft
Date Sat, 03 Nov 2012 16:47:58 GMT
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 the
> > rabbitmq one that insists that each plugin is OTP-shaped, and stopping at
> > that point.
>
> Cool, thanks. I think a “native plugins only” first step would be a great
> thing to ship. Discussion of “external plugins” can happen after that. I’ll
> 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’ll 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’s 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’d like a future where we have a solution for developer’s 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’t jump onto that particular point now,
> thanks :) and make for a leaner code base all around.
>
> * * *
>
> I’m happy to concede that you don’t agree with this future, I’m just
> 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 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).
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
>
>


-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message