avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Proposed change to Parameters:
Date Wed, 26 Sep 2001 15:13:19 GMT
On Thu, 27 Sep 2001 00:14, Berin Loritsch wrote:
> > 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.  

Agreed. ParameterSchema and ConfigurationSchema that adapt to exisitng APIs 
if possible. (ie one ConfigurationSchema impl would use DTD and one would use 
XSchema). Thats how I want to see it done long term.

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

I am not sure what you mean. The component requests from it's container that 
it wants a mutable copy of its own config data, modifies it and then passes 
it back to it's container. The container will validate using above schema and 
if it passes then everything is good.

At least thats what my understanding of it was. This was based on your work 
of rul based validation from ages ago combined with some of the things I have 
been looking at lately. Am I missing something?

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

Okay thats not what I am proposing. I was proposing that the merging all 
occurs in parent space and the child only gets a copy of final Parameters 
object. The parent gets to do merging and all tricky stuff and child is given 
simple interface.

Is there any reason why this wouldn't work?

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

I don't see Re* as a merge operation but a replace operation for all systems 
(CM, Config, Parameters and Context).

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

right. However what I am saying is that it is not a general enough concern. 
Much like ExcaliburComponentManager is not as general as 
DefaultComponentManager and is thus not kept in framework CVS but in 
excalibur CVS. 

I don't see these functionalities as sufficiently general enough to warrant 
addition to the framework CVS. I wouldn't mind it being placed in Excalibur 
but definetly not in Framework.

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

I would not agree with this. I would say that if the feature is common to a 
wide variety of scenarios, is simple and focused then it belongs in Framework 
otherwise it doesn't. ie ExcaliburCM is suitable in a range of scenarios but 
it is not simple, small and focused and hence lives in Excalibur.

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

I think you missed my point. Almost any functionality you can describe is 
useful in multiple scenarios. We don't want to add it all into Avalon though 
because kitchen-sink programming is not simple to understand, maintain and 
keep focused. 

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

Who said it wasn't considered. I looked at it and decided I didn't like it ;) 
It's not that it is not useful code. It is just not useful enough to warrant 
the complexity adding this sort of thing tends to require. 



"Sometimes its better to keep your mouth shut and 
let people think your an idiot, than to open it 
and remove all doubt." 

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

View raw message