Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of antony.blakey@gmail.com
 designates 74.125.44.28 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=r4CZjyy+lwtsVUTkiGPGtpDRHQLCwukyh8jeFlCK/Am2Es8q0sfyz8cujCLNB3KQdC
         DWnPSCapFNNNljdXPSQmLdC8tLgsF6j0Q3O5+pm0IISB7JrOmZZULDbJ7nM2ZRH9yUyQ
         RYNkgDOWmRWdDriv06w19EBEhuFqnCeMGeqkU=
Message-Id: <7C846247-143D-44E5-997C-A5CC165C7B6A@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: dev@couchdb.apache.org
In-Reply-To: <64a10fff0903121642k17352a8eh344ae673bba8541@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Bulk Docs
Date: Fri, 13 Mar 2009 10:35:35 +1030
References: <49B8FD3F.4050706@timparkin.co.uk>
 <1E890AD0-6DCE-4E06-B227-AC61DF1E72BA@apache.org>
 <F3F17098-B32A-40BC-A782-70C6E334A9DF@gmail.com>
 <64a10fff0903121642k17352a8eh344ae673bba8541@mail.gmail.com>


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.