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 <j...@apache.org> wrote: > > On Nov 1, 2012, at 11:01 , Bob Dionne <dio...@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 <si...@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). > >> > >> > >> > > > >
