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 >> -- >> >>
