avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Proposed change to Parameters:
Date Wed, 26 Sep 2001 14:14:16 GMT
Peter Donald wrote:
> 
> On Wed, 26 Sep 2001 07:00, Berin Loritsch wrote:
> > Peter Donald wrote:
> > > On Wed, 26 Sep 2001 05:31, Berin Loritsch wrote:

> > > Right. But fundamentally I don't think we should be supporting partial
> > > mutability in any sort of configuration data. We don't have partially
> > > mutable Config trees and I don't think we should support it.
> >
> > I'm not talking about config trees.  I am talking about Parameters.
> > Inherently flat data.
> 
> Configuration data is configuration data regardless of whether it is flat or
> hierarchial. You are prposing that the config data be partially mutable (Like
> making some of Configuration objects mutable but not others in a config).
> This is not something we should support IMO - hence the -1 on it ;)

Point taken.  However, we also have been talking about mutable configurations.
there does need some control over what can be modified and what cannot be
modified.  We can take the approach that the Component handles that responsibility.
However, this is not automatic, and does not provide a mechanism for a parent
to force its will over its children--IoC.

> > Getting back to setting up the Parameter object, it
> > is terribly inconvenient to do the hierarchical approach.  Plus, you have
> > an undefined action when you merge Parameters.
> >
> > For instance:
> >
> > Parameters testcase = new Parameters();
> > Parameters mergecase = new Parameters();
> > mergecase.setParameter("merge", "case");
> > mergecase.makeReadOnly();
> >
> > testcase.merge(mergecase);
> > testcase.setParameter("merge", "value");
> >
> > "value".equals(testcase.getParameter("merge")) == true // This is what we
> > don't want!
> 
> then you swap the order of merge and setParameter()?

Keep in mind this example is contrived, and does not reflect the scenario
where a Parameterizable component keeps its own copy of a Parameters object
and simply merges the contents (i.e. with a read-only Parameters object that
the parent was careful to make read only).

In that case, your glib remark cannot apply.  The order I presented was
important to demonstrate my point.  If the parameter objects are already
merged by the time I want to set "merge" to "value", but the parent wants
the data to be a constant, then I will overwrite the "constant".  This is
not good behavior.

My point becomes even more clear when we have Reparameterizable in the
picture because you will be merging the Parameters given to you with
an existing set.

> > The implementation that I propose is able to lock all parameters
> > in a read-only Parameters object--even when merged with a non-read-
> > only parameters object.
> 
> The functionality you propose partially readable and partially writeable data
> in the same object. It is not needed functionality as it can be implemented
> as I have indicated without any changes to current framework setup.

As I pointed out, there are some serious holes in your approach, that my
approach solves predictably.  I guarantee you that someone (not as careful
as you) will run into problems using your approach.

> > Requiring other projects to either change their configuration schemes or
> > reimplement ( extend or whatever ) parameters objects simply so they can
> > change what they call a parameter is kind of rediculous.
> 
> Changing Framework to reflect different configuration schemes for every
> different project Avalon is used in is ludicrous.

(I withheld using the word ludicrous ;-)

We are not changing the _framework_.  I want to make that clear.  What I am
proposing is adding _functionality_ to the framework _without_changing_ existing
behavior.

> I have a configuration scheme like Axis. Options however have other features.
> They can be "archive" options (will be written out when saving options), they
> can be "noset" (not able to be set by normal code), they can be "latch" (only
> able to be set within a specific phase), "serverinfo" (replicated to
> clients), "clientinfo" (replicated to server), etc
> 
> How many would I get to add to Avalons Parameters object? All of them, some
> of them, none of them?

We need to evaluate the change as we are doing here.  If they are applicable
in more than one setting than we have a winner.  Your "noset" option is exactly
like the "locked" option in Axis.  You have proved my point that the partially
writable Parameters object is useful in more than one setting.

As to the others: currently we have to consider all parameters to be "archive"
options unless we specify otherwise.  It can be argued that the Component
needs to manage what gets archived or not.  However, an outomatic mechanism
also helps to simplify using the Parameters.  Next, parameters are "latch"
parameters if "makeReadOnly()" is called later.  The Parameters object is
stateless--so "latch" parameters would only be useful in a StatefulParameters
object.  The "*info" parameters are sufficiently application specific to
not go into any detail here.

The only difference between "noset" and "locked" is the attribute name used
for them.

> > Adding the ability to identify the attribute names is FS (flexibility
> > syndrome).
> 
> as is adding ability to modify element names. It is a product specific demand
> to why not place it in the product and not in the framework that is meant to
> be generalized.

A framework should be designed so that there are simple methods for the
majority of cases.  However, it should also be extended as more use cases
are found.  If adding special methods to change the name of an element
and arguable even attributes does not change the simple case and allows
customization for the special case, then it should be considered.

A framework needs to be well thought out.  This is true.  It should not be
so set in stone that it is archane before you begin.  Configuration is something
that we don't have perfect yet, and it should something where we need to
evaluate new approaches as needs arrise.

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message