commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [Configuration] Proposals...
Date Mon, 17 Jun 2002 12:15:30 GMT
> From: ola.berg@arkitema.se [mailto:ola.berg@arkitema.se] 
> 
> >> 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.

Yes, and I know of at least one project using Avalon just for
the configuration.  That's still a political argument, not a
technical one.

Keep in mind the Configuration abstraction in Avalon has been
around since 1999.  It is largely unchanged (with the exception
of the package name) since then.

Why doom yourselves to repeat the effort?


> >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.

Which is one reason that it is very user-friendly.


> 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.


I don't get this requirement.  Configuration information is
configuration information even if you call it a data model.
"A rose by any other name would smell just as sweet..." to
borrow a quote.

The point is that I think you are going down the path of
more work than necessary for this.  I haven't needed anything
more than an object receiving a Configuration object to do
its work.


> 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?

Keep in mind that Avalon predates Commons.  It was there all
the time--just for your using.


> 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.


If you like a utility, and use it, do you really care where
it comes from?

I would like to see how your quite complex config system would
be better than the current simplistic approach used in Avalon.

Simplicity makes things easier to use and understand.  Complexity
kills.

I am trying to trace a bug in Visual C++ STL which, purely syntactically
speaking, should work.  The problem is all the black magic that goes
on under the scenes that is causing an Access Violation Exception
where one should never exist.

I have refactored a number of systems that where too complex when
they started out, forcing the user to know too much.  I like simplicity
because I don't have to waste 12 hours (my last Friday) trying to
chase down a bug that by all other means should not exist.

I should not have to debug Microsoft code to fix my system.  I have a
feeling that where you are starting will force users to debug commons
code to fix their system when by all other means it should work.

It's a slippery slope.  Perhaps its uncertainty on my part, I haven't
seen your work so I can't say anything one way or the other about it.
My humble suggestion to you is to start simple, and add on from there.


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message