I understand it might seem huge, but I'd like to confirm that is actually huge...
I'm proposing that (1) We confirm/deny that a sufficiently advanced CouchDB plugin; using the existing plugin system could duplicate the effects of a replication call. That only requires someone who knows to say yes or no (no work required). If yes, the work is enabling the replication UI to set the target/source URL used for replication (to trigger the plugin instead of the default URL string it uses now). While it does mean work, adding another dropdown to select a plugin does not occur to me as huge. If plugins can not replicate the behavior of a replication then, agreed, it's beyond the scope I was thinking. I'm not proposing anyone write one for the release; just that someone could. 2) To check if the contents are the same; I am only proposing that couch calculate its own revision id, using the prior rev it already knows about and the md5 method it likes, for the incoming conflicting document id and not just take the one provided blindly. If the new rev id matches an existing live doc, then keep the existing doc and discard the new one (as if the remote side had sent the newly calculated rev id in the first place). Calculating and testing a new rev id on a document just before a document saves to disk only when the document id hasConflicts does not seem a significant development work add. It could even work well with the idea of indexing the existing conflicts alongside the docId to make the comparisons quick/easy to locate/test. I'm specifically looking for a proposal that enables the ability, and is of low hanging effort; not creates a lot of work. I know it could seem huge; but are the two changes I proposed actually a big implementation effort? Thanks, Mike On Apr 18, 2016 2:10 PM, "Robert Newson" <rnew...@apache.org> wrote: > Respectfully, no. > > What you propose is huge and will take considerable time to design. 2.0 is > two years late already. > > We're all for encouraging interoperability but we'll have to address it in > a later release. > > > On 18 Apr 2016, at 21:23, Michael Fair <mich...@daclubhouse.net> wrote: > > > > Before RC1 gets locked in; would anyone be opposed to adding replicating > > with non-erlang based datastores; (I'm thinking java (android/desktops), > > c#, python, c, objective-c (ios) - not that language matters at all) be > a > > named feature for the 2.0 series? > > > > Specifically this wouldn't mean writing any code to directly support > other > > databases; just a friendly and minimal supportive effort to make it > easyish > > for others to do. > > > > Specifially, I see this meaning one of two things: > > 1) The replication system url supports an optional parameter for "method" > > (and url parameters for those respective methods) or supports a plugin > > system that uses alternate replication urls so other people can > > bootstrap/test new replication protocols; > > > > Or (and?) > > > > 2) changing how mismatched revIds from a replication are processed to > > include a simple "is this really a conflict?" secondary test. > > > > 1) > > A new experimental replication plugin feature could also be used in other > > ways; like leveraging a binary encoded format for transmission (like > > erlang's native binary encoding). Or letting a large infrastructure > > customize their replication (perhaps even going so far as using shared > > storage/direct SAN APIs to copy blocks around directly on the storage > > system); or perhaps dealing with as specialized subset of json docs > > specific to their use case/requirements (like add'l logging or encryption > > methods?) > > > > If these plugins were something people were told they should try out, I > > think they would. And it's a way people make a difference/contribute by > > allowing the plugins to be loaded without affecting the core project. > > > > And 2) > > Unless I missed something, simply doing a secondary test to see if a > > proposed conflicting document actually has different content and merging > > them when they are the same would eliminate the need for different > systems > > to generate the same revision id (eliminating the need for any system to > > need to use the revision id calc of another system). > > > > All Couch compatible systems would freely replicate without conflict > issues > > due to revision id. (if you want more efficient replication; use a > plugin > > for your database (see #1 above)). > > > > I don't know what it takes to add a plugin system / URL for replicating; > > but assuming it's relatively basic based on what's already in place, I > see > > it makes a lot of sense to do both of these. > > > > Thanks, > > Mike > >> On Apr 18, 2016 1:58 AM, "Jan Lehnardt" <j...@apache.org> wrote: > >> > >> Hey all, > >> > >> we are getting close to 2.0. In the list of blockers, there are only two > >> issues left that aren’t docs, that we’ll need some concerted help with: > >> > >> https://issues.apache.org/jira/browse/COUCHDB-2863 > >> https://issues.apache.org/jira/browse/COUCHDB-2834 > >> > >> If anyone as any spare cycles looking at any of these this week, that’d > be > >> most appreciated. > >> > >> My plan is to release a CouchDB 2.0.0 RC1 when the two issues above are > >> resolved*. We can do the blocking docs issues, Windows and Mac builds > etc. > >> during the RC timeframe. > >> > >> * although, if it turns out that the fix(es) to these will take a lot of > >> time, I’d be okay with a RC1 that lists these two as “known issues”, but > >> I’d prefer to get them closed out first. > >> > >> > >> Best > >> Jan > >> -- > >> > >> > >
