Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.217.222 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=AXmpyT45Se9Gs/hPJ87klGNlQSTxbTOz7LYP9IW/QFKudoVQ7RFfc35A34RWZk+mRn
         V+/3z3owxlrvMcWCYXnGridc0Dy1AekLa68XYIRt8A6AV96L7cqomihdzlQH2hY+0QDu
         37V5+eimwsCcsb7LaAD4ovVyoSm+Oo4r4TcrI=
MIME-Version: 1.0
In-Reply-To: <31F6CF48-13A1-4E43-ACAD-329A980764A3@dslextreme.com>
References: <4A321298.4030209@apache.org>
 <31F6CF48-13A1-4E43-ACAD-329A980764A3@dslextreme.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Fri, 12 Jun 2009 15:02:52 -0700
Message-ID: <c7d45fc70906121502v2c8fcee5r2c4c51b7fcfc4815@mail.gmail.com>
Subject: Re: [configuration] Configuration 2.0 - Persistence
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=001e680f1328e36c04046c2ddf5f

--001e680f1328e36c04046c2ddf5f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On a related topic, I am interested in building a configuration object that
pulls configuration from Zookeeper and can optionally persist back to ZK.  A
key feature would be auto-reload on change combined with a lazily copied
snapshot so that related properties could be read from a guaranteed stable
version.  I would also like to support XML and traditional syntaxes and full
configuration listener capabilities.

I would prefer not to introduce a Zookeeper dependency into Configuration so
hacking classes like FileConfiguration seems like a bad idea.  Preferably
there should be some way to do this cleanly that makes use of existing
configuration code.

In looking at the API, however, it isn't clear where to go.
FileConfiguration doesn't seem to be abstract enough and
AbstractConfiguration seems to have lots of file assumptions built in.
Likewise, there doesn't seem to be a hookable configuration where I can pass
in znode contents and use the reload policy framework.

Where should I start looking?

On Fri, Jun 12, 2009 at 7:59 AM, Ralph Goers <ralph.goers@dslextreme.com>wrote:

>
> On Jun 12, 2009, at 1:32 AM, Emmanuel Bourg wrote:
>
>  I may have some time to work on the experimental branch this summer. There
>> is a fundamental point I'd like to address, that's the persistence of the
>> configurations.
>>
>> As described in CONFIGURATION-311 I'd like to add two methods to the
>> Configuration interface, sync() and flush(), similar to the ones in the
>> java.util.prefs API. I haven't got much feedback on this idea, and I'd like
>> the make sure there is a consensus on this before proceeding.
>>
>> What do you think?
>>
>>
>>  Here is the part that confuses me. A FileConfiguration would support
> load() and save() and would have a file name associated with it. What you
> are suggesting is that Configuration should have the save() but not the
> load()? If so, where would it save to?
>
> I see value in having a Configuration where the original data, if any, is
> not loaded from a file, but the configuration can be saved to a file. For
> example, a CombinedConfiguration is constructed through the merging of
> various files but then might be saved as its own configuration.
>
> I guess I'd like to understand how you would expect the configuration to be
> associated with a file before sync gets called, what happens if it isn't,
> etc.
>
>

--001e680f1328e36c04046c2ddf5f--