> On Oct 19, 2014, at 1:49 PM, Jan Lehnardt <[email protected]> wrote: > > >> On 18 Oct 2014, at 01:17 , Jens Alfke <[email protected]> wrote: >> >> >>> On Oct 17, 2014, at 2:22 PM, Brian Mitchell <[email protected]> >>> wrote: >>> >>> 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 on. > > 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. Brian.
