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.
