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..
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. 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). A plugin architecture, in my mind, should emerge from the code refactoring and layout we're currently discussing. 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. 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). > > >
