couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Roadmap discussion
Date Mon, 09 Feb 2009 21:22:15 GMT
On Mon, Feb 9, 2009 at 4:06 PM, Chris Anderson <jchris@apache.org> wrote:
> Couch Devs,
>
> From the beginning of this project, we've had a shared vision for
> CouchDB. The best documentation of that vision (in my mind) has been
> the text available at http://couchdb.apache.org/docs/overview.html
>
> However, the project has been evolving, and we are within sight of
> reaching many of the goals outlined in the Technical Overview.
>
> I think it would be helpful to outline our progress so far, and see
> how the project can grow.
>
> So far:
>
> * REST / MVCC / ACID Document Storage
>  - This is solid (modulo _bulk_docs)
>  - Append-only file structure has turned out to be a big win.
>
> * Incremental Map Reduce
>  - This is also strong right now. It could be faster, but so far it's
> been fast enough.
>  - Ready to implement view Etags.
>
> * Live database compaction
>  - basically done.
>  - View compaction would be a nice bonus.
>
> * Incremental Peer Based Replication
>  - We're still working on non-buffering attachment replication.
>  - Multi-node security model work is in progress.
>
> * Partitioning
>  - I'm not sure how far we are along on this. Afaik, the plan is to
> split nodes into subnodes depending on load, essentially making a
> binary tree of Couches. My guess is that inner-nodes would be proxies
> and leaf nodes would handle disk. I think there's a dependency on
> getting the security model right.
>  - View queries are just a big merge-sort across all the nodes.
>
> * Full Text Search interface
>  - We've had basically working patches for this floating around for a while.
>  - It seems simple enough, we just need someone who comfortable in
> Java to step up to the plate and write a Lucene adapter. (Thanks!)
>

Not it!

> New parts:
>
> * External
>  - This was originally implemented to support Full Text indexing.
>  - People are using it as an interface to a whole range of
> app-servers and alternate indexers.
>
> * Show / List
>  - Giving CouchDB the ability to serve directly non-JSON dynamic
> content types improves it's utility for offline applications.
>
> * Notification API
>  - When Damien first mentioned the idea of holding open Comet-style
> connections for selective replication, it fit right into the bigger
> picture of Couch. I'm very interested in developments here.
>
> * Config
>  - This is an outgrowth of supporting such a big system. Luckily now
> it's powerful enough to provide an easy way to hook custom Erlang
> modules into CouchDB's HTTP stack.
>
> * Stats
>  - In-progress monitoring interface.
>
> * Alternate Storage and View Engines
>  - There are interested parties here, but I think we're hoping to
> save this one until all the deeply subtle stuff Damien's working on
> comes together.
>
> I know there is a lot of stuff I've put on here, and there's a lot
> that I've missed. Please feel free to expand the outline.
>
> I'm hoping to discuss the best way for us to focus our energies. But
> first we should know where we stand and where we want to be.
>
> Chris
>
> --
> Chris Anderson
> http://jchris.mfdz.com
>

* Miscellaneous API extensions, nothing big on their own, but taken as
whole make CouchDB more awesome. (multi-get, include_docs, stale=ok,
etc)

* The Status module/Futon page for tracking what background magic
couchdb is doing.

Mime
View raw message