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. YMMV, Bob > > 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 toda > > >> 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). >>> >>> >>> >> >
