You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2006/03/23 23:03:25 UTC

Configuration Requirements, merged, ordered

Combination of Jim's mail and mine...
I didn't have an ordering in mine so I took his.

1a Users must be able to provide custom data values for configuration
    properties and references using any Java Object.

1b Users must be able to provide mechanisms that construct those Objects
    from XML artifacts using a binding technology of their choice.

2a We need to provide mechanisms that make it easy for extension
    developers extend the configuration model. They must be
    able to contribute configuration information specific to their
    extension.

2b Manipulating the model should follow Java idioms as closely as
    possible. The implementation should use technologies familiar
    to both Tuscany developers and to other open source developers
    who may be interested in contributing to the project.

2c Extension providers must be able to provide handlers for XML
    artifacts using technologies commonly accepted and familiar
    in open source environments.

3  Operation in a variety of deployment environments. The model
    must remain easy to use/extend in different classloader
    hierarchy scenarios. It must easily support isolation between
    Host, Tuscany and application classloaders.

4a It must be able to load configuration from sources other than
    XML. Configuration may be stored in other forms e.g. as
    returned from a registry.

4b It must be able to construct configurations programmatically.
    This is intended both to support our test/bootstrap needs but
    also to support users who wish to test components that rely
    on container-provided infrastructure.

5a The implementation should be easily understood by Java
    developers wanting to contribute to Tuscany.
    [[ JNB I would move this higher ]]

6  We must be able to support multiple versions of serialized
    configuration files - for example, we must support both 0.9
    and 1.0 revision SCDL files.

7  The implementation must be able to handle large configurations (1000
    components) with reasonable performance and memory consumption and
    linear scalability.

8  The model should allow us to easily accommodate spec changes.

Thoughts?
--
Jeremy