Return-Path: 
 <river-dev-return-278-apmail-incubator-river-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-river-dev-archive@locus.apache.org
Received: (qmail 97061 invoked from network); 7 Feb 2007 10:32:37 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 7 Feb 2007 10:32:37 -0000
Received: (qmail 98548 invoked by uid 500); 7 Feb 2007 10:32:44 -0000
Delivered-To: apmail-incubator-river-dev-archive@incubator.apache.org
Received: (qmail 98533 invoked by uid 500); 7 Feb 2007 10:32:44 -0000
Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:river-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:river-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:river-dev@incubator.apache.org>
List-Id: <river-dev.incubator.apache.org>
Reply-To: river-dev@incubator.apache.org
Delivered-To: mailing list river-dev@incubator.apache.org
Received: (qmail 98524 invoked by uid 99); 7 Feb 2007 10:32:44 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Feb 2007 02:32:44 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Received: from [194.109.24.34] (HELO smtp-vbr14.xs4all.nl) (194.109.24.34)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Feb 2007 02:32:34 -0800
Received: from [192.168.1.51] (marbro.xs4all.nl [80.126.48.138])
	(authenticated bits=0)
	by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id l17AWCZZ052151
	for <river-dev@incubator.apache.org>; Wed, 7 Feb 2007 11:32:12 +0100 (CET)
	(envelope-from mark.brouwer@cheiron.org)
Message-ID: <45C9AAAC.5070306@cheiron.org>
Date: Wed, 07 Feb 2007 11:32:12 +0100
From: Mark Brouwer <mark.brouwer@cheiron.org>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Drowning in the River
References: <45C8369E.9090209@dcrdev.demon.co.uk>
	 <4aa658780702060238v4ea96c8eofbb42a5e075ea40e@mail.gmail.com>
	 <45C86EC8.2080808@cheiron.org>
 <45C8A091.9010107@dcrdev.demon.co.uk>	 <e202160f0702061222y5660fc6id69c49ccd0df5b17@mail.gmail.com>
 <1170797909.11826.4.camel@cameron>
In-Reply-To: <1170797909.11826.4.camel@cameron>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Virus-Checked: Checked by ClamAV on apache.org

Greg Trasuk wrote:

> Is there anything preventing someone from writing another implementation
> of Configuration as an alternative to ConfigurationFile?  I though Van

FYI I haven't found any problems in configuring any classes that take a
Configuration object based on configuration files that are XML based
combined with programmatic assembling at runtime (vague enough?).

I've always been very pleased with the current separation, I can imagine
though that for many people the indirection level is confusing or
awkward or whatever. However nothing prevents people for creating
Configuration factories for any of the JTSK classes that expose the
implementation details in a different way such as with setters.

The great thing is that this can be done in way that doesn't affect the
standardized/core/platform/kernel/<fill in your metaphor> classes. I can
see there are people who want to go wild with this and is Apache River a
good place for this? I think so, but IMHO not as part of the same
subproject as the <fill in your metaphor> classes.
-- 
Mark