>> My actual suggestion would be to start with the XML Configuration
>> component, along with the Testing Suite, supported by a site
>> infrastructure designed to scale to multiple components.
>
>And to test that scalabilty, lets do DBConnection Pool as well :)
I have a few concerns about this plan of attack. When we are building these
components how will this evolve. I expect at the start that they will
largely be independent. Then someone will need configuration data for DB
pool and thus they will use the XML Config component to get it. This is
integrated on top of that.
Now a bit down the line it is decided that there needs to be a way to share
connections and share components between DBPools and a native system (ie
may need to do transaction monitoring etc) so someone decides to integrate
DBPool into a service directory.
Now this DBPool is part of a framework rather than an API - and depending
on framework parts chosen (ie whos configuration component and whos service
directory - turbine, avalon or struts) we have just built yet another
framework.
We need to define clearly wear the difference between this project is and
where Avalon is.
>> Testing seems to be a hot button right now all over Jakarta. But we
>> would also need something to test. The XML Configuration component
>> saw the largest number of votes. Merging the Avalon and Struts
>> components seems manageable, and may provide a lot of
>> utility to other products.
I doubt it will ever happen. Both config frameworks are good but they serve
different purposes much like SAX and DOM are different models. They really
belong side-by-side. Neither project would get any advantage from integration.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
