commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ola Berg <>
Subject RE: [Configuration] Proposals...
Date Sat, 15 Jun 2002 23:30:34 GMT
>> 1) Is not in Avalon but in commons
>This is a stupid requirement, so I will ignore it.  
>The questions are
>purely technical, not political.  Please refrain from >making it so.

I apologize for being unclear, my reason is actually pure technical, analog to 

>What I would like to see is less duplication of effort.

The configuration tool in Avalon, being good as it is and getting better, only benefits Avalon.
In a separate package, it would benefit all.

>What it seems to me is that you want a configuration SYSTEM,
>which is more than what representing configuration information
>is about.

Absolutely so. Representing info is one thing, handling the info is another. But sketching
requirements for a good configuration framework as I am, I have to take into consideration
the information representation as well.

I didn\'t interpret the original question as limited to configuration data object only, but
I might have misunderstood it all (just as I might have misinterpreted the values-only-in-the-leafs-deal.
Going for a re-read right now). 

Configuration info a la Avalon (tree-like/document-like/ structure) is the right thing, which
means that the object you showed me is a strong candidate for usage. At least the thoughts
and concepts.

But the class itself is (unfortunately) probably not, since it states that it is Configuration
info. But it is actually the data-model that is interesting, not its usage in config context.
My view is: config needs to support this data model, rather than config _is_ this data model.
I therefore probably will go for an interface that encapsulates the pure data-type, like any
of the DynaXxx classes, or maybe the XML-model directly, without mention \"config\" anywhere.

If one doesn\'t want to see duplication of effort, this is the path I believe one has to go.
Avalon might have these great functions to handle this datatype. What if they had been put
outside Avalon in the first place, being general as they are, and not tied to config at all?

Or being \"outfactored\" from Avalon now, when one sees their generality? Insights on what
is of general applicability often come afterwards (making \"doing it right the first time\"
practically impossible), that\'s natural. In order reduce duplication of effort and promote
reuse, a refactoring might be necessary.

Anyway, thanks for the input and criticism.


0733 - 99 99 17

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message