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?
- 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))
- couch_collate nif to replace couch_drv + ejson_compare nif . Is this
OK for you? It's extensively tested there.
- 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
- 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?
Hopefully someone can answer to them. I plan to merge both branches ASAP.
- benoit
