On Nov 1, 2012, at 16:53 , Bob Dionne <[email protected]> wrote:
> > On Nov 1, 2012, at 7:53 AM, 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. > > in that case, good luck, that's a long expensive haul. > >> >>> 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 see, great. I think we have perhaps different interpretations of "user". > Given the current state of the code base I see the users as programmers > trying to extend the existing code in interesting ways. An architecture for > plugins that emerges bottoms up from those attempts, similar to how the > couch_api_wrap and couch_index refactoring came about, is what I'm interested > in. Top down high level approaches rarely work in practice *except* where > there are lots of resources and control over the process, both of which are > in short supply in open source efforts. Yup, different POV, my users are people who program against CouchDB that might want additional features that aren’t in core CouchDB. There are also plugin authors to which we need to cater, and the things you bring up definitely fall in that bucket. I just want to start things out from the end-user, that is all. We are on the same page. Cheers Jan --
