The CouchDB application we are deploying at the moment has a second
phase that makes it into a generic platform like the Notes Client. It
involves building a generic OSX/Win32/Linux GUI into which many
applications written by our client will be deployed. Because our
foundation application needs a fail-on-conflict bulk op, the CouchDB
part of the application will be a fork. Because we have to fork it
anyway, we are also looking at some other changes.
Independent of the CouchDB Ltd issue, we have been struggling with the
issue of not using the name (and even not using the Futon logo)
because of the combination of a) using a fork of CouchDB that has (at
least) not-officially-supported/officially-unsupported bulk-operation
semantics; and b) our application being a generic deployment platform
for a significant group of developers.
We view CouchDB more as a toolkit/library than a product, but sense
that the CouchDB vision is to be a product with universally defined
and supported semantics and boundaries. And there's the issue of not
misdirecting our client's developers - we don't want them thinking
that the CouchDB documentation is 100% applicable. Nor do we want to
muddy the CouchDB definition. The internal counter argument is that
using the CouchDB name even at this point has commercial advantage -
especially useful selling a new technology.
Firstly, are we correct in our assumptions about 'the CouchDB product'
with universally consistent (i.e. not configurable) semantics being
'the plan'? What are other people's thoughts/advice about these issues?
Cheers,
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Plurality is not to be assumed without necessity
-- William of Ockham (ca. 1285-1349)
