Re: [higgins-dev] configuration component requirements

["Tom Doman" <TDoman@xxxxxxxxxx>]

It also seems reasonable to me for a component to be able to describe it's
own configurable elements especially since that components configuration
may differ wildly from any other component in the system.  After all, to
know a component well, were to know itself.

That said, I wonder if that's a complexity we could live without in the first
pass.  As was apparent in the last call, we start getting into some pretty
elaborate requirements.  I'm starting to believe that, sometimes, trying to
design and implement all the bells and whistles up front is counter-
productive rather than flexibly forward thinking.  Often, we end up
refactoring by scraping what we spent a lot of time implementing because
the use cases, while potentially clear, weren't imminent (I'm looking back
at some of the course of IdAS as an example).

I'd suggest we do what we need to get a simple mechanism in place, make
sure we don't design ourselves out of the ability to query component
configuration capability (shouldn't be too hard) in the future but that we
refrain from fleshing out a design and implementation for the time being.

Tom

>>> Greg Byrd <gbyrd@xxxxxxxx> 5/18/2007 9:23 AM >>>
OK.  I think I do understand the concept, but I apparently have a different intuition
about what it means for a component to be configurable.  

If a component is configurable, that tells me that there are knobs that I can set.
But it also seems reasonable for me to look at that component and ask, "What are your
knob settings?"  You're saying that's not the responsibility of the component.  Fine, 
I can live with that.  If desired, the management application can keep its own
records about past/current configuration settings.  

Is that fine with everyone else?

...Greg


Michael McIntosh wrote: 

I think maybe you misunderstand what a configurable component is - it is 
just a component that can be configured thru the API - It is not a repo 
for configuration data.
I do not think a configurable component should be responsible for caching 
and providing its configuration to management applications.
I think management applications should invoke the configure method during 
initialization and whenever the configuration changes.

Thanks,
Mike

higgins-dev-bounces@xxxxxxxxxxx wrote on 05/18/2007 10:18:46 AM:

  

Mike, you've included separate maps for global vs. component-
specific settings.  I understand the motivation for this, I think, 
but how far do you think this separate should be continued?  For 
example, it seems to me that there should be a getConfiguration 
method for IConfigurableComponent, so that a management application 
(for instance) can retrieve the settings and present them to a user.
Should the component therefore keep the two sets of setting 
separate, and should there be separate getGlobalConfig and 
getComponentConfig methods to retrieve them?

...Greg



Michael McIntosh wrote: 
I checked in several projects earlier today including:
        org.eclipse.higgins.configuration.api
        org.eclipse.higgins.configuration.common

Thanks,
Mike

  _______________________________________________
higgins-dev mailing listhiggins-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/higgins-dev    _______________________________________________
higgins-dev mailing listhiggins-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/higgins-dev