A clarification of container aspects: Ignoring just how they are to be implemented, this is the goal:
To start off with a simple framework (not referring to Avalon/framework), and then implement the existing Merlin on top of it as a set of aspects, thus making basically all parts of Merlin optional and replaceable. We'd end up with the existing Merlin, but with all features optional. (Then we could group features into micro/standard/enterprise, and get three well-defined platforms, or ...) > -----Original Message----- > From: J Aaron Farr [mailto:[EMAIL PROTECTED] > 1. Why do I use Avalon? It provides a very good set or architectural patterns that I have found applicable to a wide range of applications. It has also enabled code re-use. My original motivation for using Avalon was "unless we use this we have to come up with something just like it". > 2. What do I feel Avalon's mission to be? Evolve the Avalon framework, a framework primarily for server-side applications. > 3. Where do I see Avalon by the end of 2004? Is this "where I want us to be" or "where I realistically think we'll be"? I want us to be a place where we have *one* product that scales from lightweight to full appserver. Where I think we'll be is "not there" - the focus seems to be on the appserver side of the spectrum. Rather, the people aiming for the appserver side seem less receptive to the lightweight vision than the lightweight side to the appserver vision. > 4. How do I feel about Avalon as an umbrella project vs. a single > product? Somewhere in the middle. I've been a fan of a Java-like Micro / Standard / Enterprise division of the "single product". I don't know where that places me on the spectrum. We can't go on with a multitude of separate codebases, though. Promoting code re-use and evangelizing about how good Avalon is for that doesn't sound very good when we fail completely ourselves... > 5. Should there be a formal framework specification? Yes, a short one. > 6. If so, what should it consist of? The framework spec should consist of... Avalon/Framework. There are holes in the framework API spec as it is now - for example, poolable components (ECM) versus all-components-are-singletons (Phoenix). Those should be plugged to enable component compatibility. /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
