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 <[email protected]> wrote: > > On Nov 1, 2012, at 12:57 , Robert Newson <[email protected]> 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 <[email protected]> wrote: > > > >> > >> On Nov 1, 2012, at 11:01 , Bob Dionne <[email protected]> > >> 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 <[email protected]> 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
