Ralph Goers schrieb:
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.
Ralph
There are certainly some use cases that would benefit from a generic
flush() method, e.g. just tell a composite configuration to save its
changes, and it iterates over its children and flushes them.
However, there are lots of details that have to be cleared, for instance:
- How are configurations treated that are not really "compatible" with a
manual save operations, e.g. JNDIConfiguration or DatabaseConfiguration?
- What about pure in-memory configurations?
- Or URL-based configurations without a valid URL?
Not sure how a sync() operation would fit into the concept of the
library. I assume it is like a manual reload, but (in addition to the
questions above):
- What happens to changes performed on the configuration objects? Are
they overridden? Is a merge tried?
- When in the life-cycle of a typical application should the sync()
method be called?
Solutions to these questions are not easy and may sometimes be non
intuitive. So I worry this might be confusing for users and generate
some Jira tickets.
In summary: I see some use cases for this feature, but I wonder whether
it is worth the effort.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
