couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <adam.kocolo...@gmail.com>
Subject Re: improve the bigcouch and rcouch merges
Date Wed, 22 Jan 2014 17:52:20 GMT
Definitely agree that the INI system is friendlier than forcing everyone to write configuration
using Erlang terms.  I'm not inclined to change that, and in general I'd like to try to avoid
situations where the config value is actually parsed into a complex Erlang term if possible.

I'm guessing that Benoit was after making the internal access look a bit more OTP-ish, and
possibly more performant.

Adam

On Jan 22, 2014, at 12:47 PM, Mutton, James <jmutton@akamai.com> wrote:

> 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.
> 
> </JamesM>
> 
> 
> 
> 
> On 1/22/14 6:27 AM, "Adam Kocoloski" <kocolosk@apache.org> wrote:
> 
>> On Jan 22, 2014, at 9:13 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
>> 
>>> On Wed, Jan 22, 2014 at 3:55 AM, Adam Kocoloski <kocolosk@apache.org>
>>> wrote:
>>> 
>>>> 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
>>>> optional
>>>> by embedding the defaults in the code).  I'd also say that the
>>>> fabric.erl
>>>> 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
>>> to
>>> compile from a nginx like format to erlang config file we compile from
>>> ini
>>> files? In that case couchdb will have only to fetch the config using
>>> Erlang
>>> config system.
>>> 
>>> - benoit
>>> 
>>> [1] https://github.com/basho/cuttlefish
>> 
>> 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.
>> 
>> Adam
> 


Mime
View raw message