Following the initial discussions on the pmc concerning avalon direction, roadmap, etc. I wanted to post my thoughts about Avalon and the direction over the next year.
1. Development Consolidation ----------------------------
One api, one reference implementation. Rather than launch into a A5 scenario, I am in favor of moving forward by building and evolving on A4 - no radical change - but some significant and important changes in the terms of depth.
1.1 Starting with Avalon Framework 4.2 --------------------------------------
More and more I'm seeing the need for different levels of APIs. We have the A4 framework contract for classic container/component interaction - but room for evolution with respect to constructor management. I see this as an avalon framework 4.2 release.
1.2 Increasing depth --------------------
Beyond the classic container/component model we have components that interact in a privileged way with a container as part of an application solution. This requires a formal API to describe meta info, meta data, and ultimately a runtime meta-model.
A starting point for a meta-model API is already in place:
avalon-meta-api avalon-logging-api avalon-composition-api avalon-repository-api
1.3 Reference implementation ----------------------------
Probably the most important thing that will need to happen in the coming months is the elimination of different development directions. One component architecture - one development community - one roadmap. This involves the establishment of one and only one reference implementation - termination of divergent streams, and the focus by the community of the evolution of the reference implementation.
2. Systems Level Development ----------------------------
On the presumption of a single reference implementation there are a number of development areas that I think are central to Avalon development:
* security services * persistence state services * transaction services * management services
The above services would be closely tied to a set of container SPIs are would leverage privileged access to system internals. The framework for much of this is already in place though the work of SPI interfaces under the composition, repository and meta packages.
3. Avalon Component Library ---------------------------
There are a number of aspects to address with respect to an Avalon Library.
3.1 Compliance with Avalon-Meta and block packaging specs. ----------------------------------------------------------
A most important factor is the requirement for single component model compliance. Usage of standard meta-info across the board, standard packaging of composite components, and a very complete and consistent approach to the definition of remotely deployable units. In other words - making sure that the component library is very easy to use and very simple to leverage.
3.2 Content Publication -----------------------
A second aspect concerns publication of library content and the services supporting this. With the introduction of consistent and validated deployment descriptors the potential exists to provide automation of the component retrieval process - similar the avalon-repository services, but instead of dealing with jar files - we are dealing with block descriptions retrieval and/or creation based on service requests. I see this as a general goal the has as a prerequisite the points identified under sections (1) and (2) above.
3.3 Library as a managed Avalon product. ----------------------------------------
Thirdly - there is the subject of the focus of an avalon library. I see several advantages in viewing the library as a managed platform - as distinct from a place for arbitrary components. As a managed platform we should be treating the library as a product in its own right - evolving components relative to the Avalon RI, maintaining consistency between components, and ensuring that no overlaps in functionality exist.
Stephen.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
