couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: rcouch merge: integration with the bigcouch branch questions
Date Fri, 04 Jul 2014 16:38:22 GMT
On Fri, Jul 4, 2014 at 5:01 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
>
> Some blocking points/questions I have about the integration of rcouch
> and bigcouch.
>
>
> - OTP release: the bigcouch and the rcouch branches are quite similar
> but I still wonder about the usage of this configure script. Is this
> really nedded? Can't we just rely on a makefile?


I'd think it'd be possible to figure out something for this. I really
don't consider it a "configure" script so much as a "bootstrap"
script. Could very well be possible to put this into a Makefile. I
don't think this is a merge blocker though as its a relatively minor
change regardless of what we decide.

> - HTTP api. some recent additions have been made in couch_mrview that
> added chttpd usage. Which makes this functions unsable with the
> standalone HTTP api. Also the couch application  in the bigcouch
> branch still contains couch_httpd* modules. Rcouch extracted them in a
> full erlang app: couch_httpd. My question is do we still need the
> legacy api (my understanding is that it is still used as standalone
> node frontend in bigcouch) ? If yes I propose to have a better
> separation in the api. There maybe 2 ways:
>     - port the couch_mrview http modules to chttpd for the layer part
> *and* couch_httpd
>     -  have different functions or better modules for chttpd and
> couch_httpd in couch_mrview (couch_mrview_httpd_*.erl and
> (couch_mrview_chttpd_*.erl))


The chttpd/couch_httpd_* split is a bit historical. The merge plan has
been to maintain the separation through the merge and then have
post-merge work that will parameterize them at runtime to work with
either single-node or clustered APIs underneath. As to extracting them
into a separate app that's not impossible but not something we've done
in the BigCouch branch because it hasn't happened on master. I think
it'd be a good idea to do post bigcouch merge when we're bringing in
rcouch.

> - couch_collate nif to replace couch_drv + ejson_compare nif . Is this
> OK for you? It's extensively tested there.


We don't use ejson_compare at all so from the BigCouch point of view
it's just a matter of replacing couch_drv which would be fine by me.
The only thing I remember about couch_collate was wanting to
investigate the way that the collation contexts are moved around as it
looked fairly complicated. But mostly I think that comes down to
measuring how heavy weight of an operation it is to create and destroy
those contexts.

> - how the fauxton build is handled right now in the bigcouch branch.
> What are requirements to make it automatic? (no manual installation).
> Is there a way to disable it


We haven't spent too much time on Fauxton yet so I don't have much to
add here. I was under the impression that its build system was
divorced from the autotools build enough that it'd be easy to slip
into a rebar build at some step. I'm not sure what you mean about
manual installation or disabling it.

> - I don't see any unittests about the sharding api. How to test the
> view changes is correctly working in the sharding api? How does
> cloudant?


We certainly don't have the best test coverage for mem3/fabric.
Internally there are some Python based integration tests that are used
as part of our build system. We've certainly thought about refactoring
this layer to provide better testability but have never had the time
or priorities to make it happen. We've considered open sourcing some
of our integration test suites but so far the priority has been to get
the bigcouch merge done before we go trying to extract all of that
code.

> Hopefully someone can answer to them. I plan to merge both branches ASAP.
>
> - benoit

Mime
View raw message