couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mutton, James" <>
Subject Re: improve the bigcouch and rcouch merges
Date Wed, 22 Jan 2014 17:47:39 GMT
The whole escript then erl regenerating the appconfig thing kind of makes
me gag a bit (then again, I have 2 sick kids downstairs).  IMHO, that
feels like the wrong direction to make it "easier".  Why not have the
app.config exist simply to tell the config module where/how to get its
config data, the default being INI.  There's a function inside config to
parse_ini file, that could just as easily be parse_json (I always wondered
why it wasn't JSON) or parse_app_env, and which one it uses is passed in
the OTP way through couch.config.  This way someone can dynamically inject
which mode they need/want, including things we haven't thought of, or not
touch it and have it behave the same way it does today.  Sane defaults
could be supplied in one location via an include (config.hrl).

The INI configuration as it stands today is quite helpful in that it
doesn't require non-erlangers to be forced subtly into erlang in order to
use couch and it's readily parse-able by other languages.


On 1/22/14 6:27 AM, "Adam Kocoloski" <> wrote:

>On Jan 22, 2014, at 9:13 AM, Benoit Chesneau <> wrote:
>> On Wed, Jan 22, 2014 at 3:55 AM, Adam Kocoloski <>
>>> Agree, great discussion here.  I will say that I think the INI
>>> configuration system is quite nice, and that I'd love to see
>>>couch_config /
>>> config gain wider adoption as an alternative to using OTP application
>>> environments (of course we should still make the INI file itself
>>> by embedding the defaults in the code).  I'd also say that the
>>> interface has a number of warts that I'd love to clean up sometime.
>> What about having something like cuttlefish [1] from Basho. But instead
>> compile from a nginx like format to erlang config file we compile from
>> files? In that case couchdb will have only to fetch the config using
>> config system.
>> - benoit
>> [1]
>I suppose that could work.  I found the restriction of keys as atoms in
>the Erlang application environment constraining, but I guess config
>sections could always be implemented using dotted notation like
>application:get_env(couch, 'database_compaction.doc_buffer_size').  I'd
>probably still prefer a wrapper around the raw interface to do things
>like supplying a default value if the environment doesn't contain one.

View raw message