What Bob said, this thread isn’t about designing new features, this is to get 2.0 — finally — out.
Best Jan -- > On 19 Apr 2016, at 04:24, Michael Fair <[email protected]> wrote: > > 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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 >>>> -- >>>> >>>> >> >> -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
