> From: Rob Oxspring [mailto:[EMAIL PROTECTED]]
> What I'm after is a volunteer from each group to edit together summaries > of the intersting / important discussions within their own group over the > course of June, and send me the result by the end of Sunday. It would be > good (though not essential) if you could let me know that someone will be > taking on the task for your project, so that I can reduce the general > pestering in later mails . Any groups that submit nothing will simply not > feature as I have not got the time to browse and edit the discussions myself. Rob, we at the Avalon group have just the thing for you since we are at a point where we want to gather user feedback. The Avalon team is in the process of identifying the requirements for a new version of the Avalon Framework. The changes are minimal, and focus on a tighter definition of the contract between the container and the component. The container is the code that manages all the components and how to access them. The Avalon team has identified some anti-patterns related to its use, and wants to provide a way to make it easier to use correctly. What we want to find out from the community at large is: 1) Are you currently using Avalon in one of your projects? 2) If not, what would it take for you to consider using it on a future project? 3) If yes, what did you like best? What were your greatest challenges? If you could choose one way to improve Avalon, what would it be? I'm not sure how we want to handle the communication. If they post their comments to [EMAIL PROTECTED] I can moderate them through. The development team reads that list. Slated for the next version of Avalon already: 1) Enhanced Meta Data. We are unifying the way we define meta data for the components. This allows the component to be used in any Avalon compliant container with zero issues. Previously you had to find out how any one container defined meta information (like version, whether the component is threadsafe or not, etc.). 2) (Tentative but likely) Standard way of extending the component lifecycle. Avalon already has a rich lifecycle management system, but sometimes you need an application specific extension. We have plans of allowing that to happen, and use any of the existing containers. 3) Enhanced tutuorials, user documentation. The new docs (when written) will focus first on how to use Avalon (the biggest complaint about our documentation). It will then present the anti-patterns that Avalon is supposed to address, and the patterns it uses to solve those issues. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
