couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: Bulk Docs
Date Fri, 13 Mar 2009 00:05:35 GMT

On 13/03/2009, at 10:12 AM, Dean Landolt wrote:

> Will this code still be Apache?

License, yes.

> Meaning, will some of this features be able
> to meander their way back into couch? I can totally understand the  
> need for
> a fork (differing goals sometimes cannot be reconciled), but if it's a
> friendly fork, so to speak, everybody benefits -- especially if some  
> of
> these features get rolled back in to make it easier for you to keep  
> up with
> trunk otherwise.

I don't want to pollute this list with OT discussion of something that  
isn't CouchDB ...

My plan changes the layering/modularity model which would make a merge  
more difficult. And there are other decisions which make might make  
merging impossible. Sometimes simple changes have ripple effects,  
which is especially evident once you wrap your head around the  
relevant literature in this space. These really are different goals,  
and to paraphrase you, CouchDB can't be all things to all people -  
wishing it to be so has caused conflict, and allowing it to be so  
would both dilute effort and result in a not-good-at-anything outcome.

Having said that, two features in particular: an immutable model of  
fully reified state and (somewhat) generalised derivation are possible  
in CouchDB. I've argued unsuccessfully for the first, and the second  
(modulo all data being JSON, hence less practical IMO) has been  
approached a number of times as _external indexing, but hasn't  
received much focus - in any case, it's more complicated in a loosely  
coupled clustering model.

I'm also interested in easing the adoption in enterprise shops, which  
has significant implications.

Antony Blakey
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

All that is required for evil to triumph is that good men do nothing.

View raw message