> On 19 Oct 2014, at 20:15 , Brian Mitchell <[email protected]> wrote: > > >> 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.
I can’t parse this, can you rephrase? :) > 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. Hence my strawperson proposal that we can work on. I envision all implementors getting a say in what works for them and what doesn’t and that we find a consensus and a solution that we can roll this out harmlessly. Best Jan --
