You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2016/04/18 10:57:44 UTC
Closing in on 2.0
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
--
Re: Closing in on 2.0
Posted by Alexander Shorin <kx...@gmail.com>.
On Mon, Apr 18, 2016 at 1:35 PM, Andy Wenk <an...@apache.org> wrote:
>> On 18 Apr 2016, at 10:57, Jan Lehnardt <ja...@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
>
> it seems that there is already a PR from Alex. Does it just need review?
My PR solves the problem in a wrong way. Actually, there I'm hiding
the real issue, caused by couch_key_tree, according Paul Davis
comment. So our "princess" is in another castle across the dragons
land.
--
,,,^..^,,,
Re: Closing in on 2.0
Posted by Andy Wenk <an...@apache.org>.
> On 18 Apr 2016, at 10:57, Jan Lehnardt <ja...@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
it seems that there is already a PR from Alex. Does it just need review?
Cheers
Andy
> 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
> --
>
Re: Closing in on 2.0
Posted by Jan Lehnardt <ja...@apache.org>.
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 <mi...@daclubhouse.net> 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" <rn...@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 <mi...@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" <ja...@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
>>>> --
>>>>
>>>>
>>
>>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: Closing in on 2.0
Posted by Robert Kowalski <ro...@kowalski.gd>.
I have a bug we are recently running into.
Our CI system for Fauxton uses fresh builds of 2.0. We _sometimes_ get
a 503 error from Couch when we try to create our test database. We
boot Couch and wait 30 seconds, raising to 120 seconds did not help.
Example build: https://travis-ci.org/robertkowalski/couchdb-fauxton#L4039
It looks like the 503 comes from:
https://github.com/apache/couchdb-chttpd/blob/be1e959504ac7b0332110a9918365ff20937bc43/src/chttpd.erl#L863
The 503 error stays for the whole 30min our testsuite runs, so giving
it more time after boot probably also wouldn't help.
Our setup for travis is quite standard, we get the Couch master, build
it, and run ./dev/run, see
https://github.com/apache/couchdb-fauxton/blob/master/.travis.yml
On Tue, Apr 19, 2016 at 9:54 AM, Michael Fair <mi...@daclubhouse.net> wrote:
>> blockers, not new work. And, yes, I still believe you are proposing
>> something major, with ramifications that require real thought.
>>
>
>
> Thanks guys :)
>
> Mike
Re: Closing in on 2.0
Posted by Michael Fair <mi...@daclubhouse.net>.
> blockers, not new work. And, yes, I still believe you are proposing
> something major, with ramifications that require real thought.
>
Thanks guys :)
Mike
Re: Closing in on 2.0
Posted by Robert Newson <rn...@apache.org>.
Please move this to its own thread, we're discussing the final, existing 2.0 blockers, not new work. And, yes, I still believe you are proposing something major, with ramifications that require real thought.
After 2.0, I'm sure we'll want to discuss improving interoperability, especially around the rev algorithm. Please don't derail this push to release 2.0.
> On 19 Apr 2016, at 03:24, Michael Fair <mi...@daclubhouse.net> 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" <rn...@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 <mi...@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" <ja...@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
>>>> --
>>
>>
Re: Closing in on 2.0
Posted by Michael Fair <mi...@daclubhouse.net>.
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" <rn...@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 <mi...@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" <ja...@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
> >> --
> >>
> >>
>
>
Re: Closing in on 2.0
Posted by Robert Newson <rn...@apache.org>.
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 <mi...@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" <ja...@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
>> --
>>
>>
Re: Closing in on 2.0
Posted by Michael Fair <mi...@daclubhouse.net>.
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" <ja...@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
> --
>
>