couchdb-replication mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Mitchell <>
Subject Re: rev hash stability
Date Sun, 19 Oct 2014 18:15:38 GMT

> On Oct 19, 2014, at 1:49 PM, Jan Lehnardt <> wrote:
>> On 18 Oct 2014, at 01:17 , Jens Alfke <> wrote:
>>> On Oct 17, 2014, at 2:22 PM, Brian Mitchell <>
>>> Giving revs meaning outside of this scope is likely to bring up more meta
>>> discussion about the CouchDB data model and a long history of
>>> undocumented choices which only manifest in the particular
>>> implementation we have today.
>> That does appear to be a danger. I'm not interested in bike-shedding; if the Apache
CouchDB community can't make progress on this issue then we can discuss it elsewhere to come
up with solutions. I can't speak for Chris, but I'm here as a courtesy and because I believe
interoperability is important. But I believe making progress is more important.
> +1000. I think so far we’ve had a brief chatter about this and we are ready to move
> How does moving this to a strawperson proposal sound? E.g. have a ticket, or pad, or
gist somewhere where we can hammer out the details of this and what the various trade-offs
of open decisions are?
> JIRA obviously preferred, but happy to start this elsewhere if it provides less friction.

My primary point is that interoperation does *not* require the rev hashes be done the same.
Clustering does but I can’t see why we’d encourage people to write the same thing to two
slightly different systems simultaneously. Doing that, I can guarantee that rev problems will
not be the only thing to fix.

If we want to define rev interoperation in terms of the minimal and the stronger case, that
might work just fine but defining interoperation as the latter is excludes a variety of strategies
that implementations can have and will likely mean different versions of CouchDB don’t “interoperate”
under this very definition, which is simply not a useful way to describe the situation.

Finally, if we really want to define a stable digest, I’d suggest that a reference implementation
be created and proposed rather than forced upon the implementations before it materializes.
This could possibly be made an option in the CouchDB configuration or build allowing it to
be an experimental feature.


View raw message