Requirements for SCA Cconfiguration

[Jeremy Boynes <jb...@apache.org>]

I think the loading discussion has been getting confused because we 
don't have a clear set of requirements defined. In an attempt to clarify 
this, here are the ones I have in mind:

* We need to be able to configure Tuscany in a test environment to
   support programmatic unit and integration tests. This should not
   require loading of any external configuration files.

* We need to provide a mechanism that users can use to configure
   container support when programatically testing their configurations.
   This should not require loading of any external configuration files.

* We need to be able to configure Tuscany from XML artifacts. These may
   be files, they may be other resources such as URLs or data streams.

* We need to provide mechanisms that make it easy for extension
   developers to meet all the above requirements. Developers must be
   able to contribute configuration information specific to their
   extension.

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

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

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

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

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

* The implementation must be easy to maintain long term for a typical
   project participant (remembering that many participants will be
   more interested in their extension than in model parsing).

Did I miss anything?
--
Jeremy

Re: Requirements for SCA Cconfiguration

[Jim Marino <ji...@gmail.com>]

Can you take a look at mine too and let me know what you think -  
Perhaps we could put your use cases in that context? I'm happy to  
work the other way around but figured it may be easier with we also  
start taking a stab at ordering.

Jim


On Mar 23, 2006, at 1:23 PM, Jeremy Boynes wrote:

> Jim Marino wrote:
>
>> I had a bunch of additional things and organized slightly  
>> differently. Do you think it would make sense to create a set of  
>> requirements in absolute priority order and fold these into that?
>>
>
> Ordering would be good - let's just get a list :-)
> --
> Jeremy
>
>
>

Re: Requirements for SCA Cconfiguration

[Jeremy Boynes <jb...@apache.org>]

Jim Marino wrote:
> I had a bunch of additional things and organized slightly differently. 
> Do you think it would make sense to create a set of requirements in 
> absolute priority order and fold these into that?
> 

Ordering would be good - let's just get a list :-)
--
Jeremy

Re: Requirements for SCA Cconfiguration

[Jim Marino <ji...@gmail.com>]

I had a bunch of additional things and organized slightly  
differently. Do you think it would make sense to create a set of  
requirements in absolute priority order and fold these into that?

Jim

On Mar 23, 2006, at 12:28 PM, Jeremy Boynes wrote:

> I think the loading discussion has been getting confused because we  
> don't have a clear set of requirements defined. In an attempt to  
> clarify this, here are the ones I have in mind:
>
> * We need to be able to configure Tuscany in a test environment to
>   support programmatic unit and integration tests. This should not
>   require loading of any external configuration files.
>
> * We need to provide a mechanism that users can use to configure
>   container support when programatically testing their configurations.
>   This should not require loading of any external configuration files.
>
> * We need to be able to configure Tuscany from XML artifacts. These  
> may
>   be files, they may be other resources such as URLs or data streams.
>
> * We need to provide mechanisms that make it easy for extension
>   developers to meet all the above requirements. Developers must be
>   able to contribute configuration information specific to their
>   extension.
>
> * Extension providers must be able to provide handlers for XML
>   artifacts using technologies commonly accepted and familiar
>   in open source environments.
>
> * Users must be able to provide custom data values for configuration
>   properties and references using any Java Object.
>
> * Users must be able to provide mechanisms that construct those  
> Objects
>   from XML artifacts using a binding technology of their choice.
>
> * 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.
>
> * The implementation must be able to handle large configurations (1000
>   components) with reasonable performance and memory consumption and
>   linear scalability.
>
> * The implementation must be easy to maintain long term for a typical
>   project participant (remembering that many participants will be
>   more interested in their extension than in model parsing).
>
> Did I miss anything?
> --
> Jeremy
>
>