Mailing-List: contact couchdb-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Cc: couchdb-user@incubator.apache.org
Message-Id: <1D706477-4D79-451E-9C0A-862A9D8F0987@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: couchdb-dev@incubator.apache.org
In-Reply-To: <20080411105447.GA21676@bytesexual.org>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: server configuration stuff
Date: Fri, 11 Apr 2008 13:42:18 +0200
References: <2C5BFE50-C6FA-4A08-BEF6-EA8658A183BC@gmail.com>
 <20080411105447.GA21676@bytesexual.org>


On Apr 11, 2008, at 12:54, Noah Slater wrote:
>
>> I'm not very comfortable with changing the config file =20
>> programmatically.  In
>> that case I'd want to be able to validate its structure after a =20
>> change to make
>> sure nothing broke (and I am not suggesting XML here). On the other =20=

>> hand, if
>> we can make that reliable, I might feel better.
>
> See above example of a Python library that can parse, serialise and =20=

> validate INI
> style configuration files. I am sure that similar libraries must =20
> exist for other
> languages.

If we can find or port this to Erlang: Very cool :) I'd rather not =20
introduce a dependency on Python (or any other language for that =20
matter).


>> The use of JSON sounds nice as it removes a possibly tedious and =20
>> error prone
>> parsing and generating step for the config module and I think JSON =20=

>> is enough
>> of a plaintext format to qualify for a configuration file.  People =20=

>> dealing
>> with CouchDB would need to know JSON anyway and for those who don't =20=

>> it is easy
>> enough to read.
>
> As I mentioned before, the INI style configuration is a de facto =20
> standard and we
> should use it if we can for that reason alone

I'm personally not seeing INI files as a de facto standard, but I =20
don't care either way as long as things are robust on easy to use. If =20=

INI does that job, it is very welcome.


> I think it is a false argument to suggest that people dealing with =20
> CouchDB need
> to know JSON - any corporate database will have many people all =20
> interacting with
> it at various levels. You can't expect the system administrators to =20=

> know or care
> about JSON or to want to use a web based interface for configuration.

Hence my sentence finished with: "=85 and for those who don't it is easy =
=20
enough to read." Any junior DBA should be able to read a key-value =20
list marked up in JSON. But as cleared on IRC, we are in violent =20
agreement here.

Cheers
Jan
--