Re: [higgins-dev] configuration component requirements

[David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx>]

I also agree.  The first priority
(IMHO) is to be able to pass in a bag of key value pairs to a configurable
component. Second priority is to be able to create a configuration object
from a datasource.  The third priority is to develop a way to express
the configuration schema of the configurable component.  The last
priority would be to query a component for its current settings.  

Getting the configuration schema for
management purposes is a deployment issue. A management app needs to import
the configuration schema before the component is loaded.  It would
not be necessary to have an API to extract the configuration schema. The
use case would be: 

Management app

   M1.  Management application
loads the component configuration schemas
   M2.  Administrator
sets the component configuration values
   M3.  Management app
serializes the configuration to a datasource

Higgins consumer application (an app
that loads and uses one or more Higgins components)

   A1.  Higgins consumer
application initializes and creates the configuration object from the datasource
   A2.  Consumer app
initializes the Higgins components by passing in the configuration object.

   A3.  Consumer app
 may later pass an updated configuration object to reconfigure some
values of the component. 

A2 and A1 are the highest priority and
the other priorities can be in later stages.  Reading from a datasource
could also be limited to a single source type and format, as long as it
does not preclude other types and formats.  

David 

David Kuehr-McLaren 
Tivoli Security
919.224.1960

Greg Byrd <gbyrd@xxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

05/18/2007 12:59 PM

Please respond to
"Higgins \(Trust Framework\) Project developer discussions"        <higgins-dev@xxxxxxxxxxx>

To	"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
cc
Subject	Re: [higgins-dev] configuration component requirements

Sure, I agree.  Note that I wasn't addressing the
issue of describing the configurable elements.
I was only assuming that the object would regurgitate the simple map that
it was given -- what
are your current settings?  As opposed to, what things can I potentially
set?

But the simplest method is "set it and forget it", from the component's
point of view.
And that's what I intend to address in this first round.

...Greg


Tom Doman wrote: 
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
 

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
  
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev