couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Apache sub-projects
Date Fri, 14 Aug 2009 22:49:33 GMT
On Fri, Aug 14, 2009 at 3:17 PM, Noah Slater<> 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.


> Thanks,
> --
> Noah Slater,

Chris Anderson

View raw message