couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Fair <mich...@daclubhouse.net>
Subject Re: Closing in on 2.0
Date Mon, 18 Apr 2016 20:23:44 GMT
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" <jan@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
> --
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message