On Fri, Aug 14, 2009 at 3:17 PM, Noah Slater<[email protected]> wrote: > On Fri, Aug 14, 2009 at 03:11:45PM -0700, Will Hartung wrote: >> Taking lounge as an example, if Couch intends to offer "lounge >> capability" as a first class service, and, in the end, obsolete >> lounge, then the decision needs to be made whether to "incorporate and >> absorb" lounge, or, effectively, "compete against" lounge. >> >> Making it a 'sub project', leads more towards the former "incorporate" >> option. If it intends to compete, then, clearly, lounge has no formal >> place within the project. >> >> Mind, even if lounge in its current incarnation goes against the way >> "most folks" would want to eventually see lounge-like capability >> implemented in couch (i.e. native erlang rather than a bolted on, >> external service, or whatever), incorporating the existing project >> with the intent towards incorporation helps funnel the energy and more >> formally direct the effort. > > I think that this might form a nice guiding principal: > > All sub-projects will eventually be merged into CouchDB, or abandoned. > > Are there any flaws to this approach?
I was actually thinking of it from the opposite direction. First of all let me say that the 3 projects I nominated follow the Django tests, and will be kept up to date with CouchDB as new versions are released. That is part of what made picking those 3 so easy. Focussing on Lounge: I see a future where Lounge is ported piece by piece to Erlang. The Lounge architecture is sound, and there are advantages to porting eg, the message passing from HTTP / JSON to Erlang terms. There is also the advantage of interoperability with existing stacks (which the current Lounge implementation is awesome at.) I also think "remixes" like an Erlang smart proxy behind an nginx running dumbproxy, might turn out to be useful. I'm merely speculating, but I think if we build a pure-Erlang CouchDB cluster, getting there by working from the current Lounge implementation, and porting parts of the service to Erlang, will give us a cleaner, stronger code base. Both for CouchDB core as well as in the Lounge. > All sub-projects will eventually be merged into CouchDB, or abandoned. I'd like to see Lounge as a sub-project precisely because I don't want to see it merged into CouchDB. CouchDB is not just targeting multi-node clusters, but also smartphones and in-browser operation. This makes me think of Django's principle: "contrib packages should be removable." CouchDB core should remain focused on reliability and performance on a single node. If CouchDB Lounge is maintained as both HTTP / Python tools, as well as a set of Erlang applications you can run inside a CouchDB beam machine, then we'll have all the benefits of an Erlang Lounge, with the discipline and code clarity that will come from refactoring CouchDB core to better support Erlang Lounge clients. There is a lot of code that can go into monitoring a large cluster, and our Erlang Lounge will eventually want to provide cluster health services as well. There are also optimizations (like view row reshuffling) which are only appropriate on very large clusters, so they should not be part of the core project, but we want to encourage their development. The modularity we'll get from being able to deploy the most appropriate combination of nginx, twisted python, erlang, etc to monitor a cluster will serve us well in the long run, I hope. I guess part of what it means to bring in a sub-project is an acknowledgment that the project we're bringing in reflects CouchDB's goals and architecture, but might not be appropriate to deploy for all the use cases we want to support. There is a similar story to tell about CouchApp and Lucene, but I'll spare the details. Chris > > Thanks, > > -- > Noah Slater, http://tumbolia.org/nslater > -- Chris Anderson http://jchrisa.net http://couch.io
