1. Why do I use Avalon?
Its an object model and infrastructure that is precisely the right abstraction in terms of the daily requirements I have in architecture and technical development - and has the potential to provide the long term strategy for the things I want to do in my spare time.
2. What do I feel Avalon's mission to be?
Generally speaking - our current missing as defined by the Board "open source software for component and service management" remains the right scope statement - but to get into more detail:
* strong rigorous specifications * infrastructure, systems and tools * core components
3. Where do I see Avalon by the end of 2004?
Good solid content in the developer tools area. Hopefully a very solid component type specification (including the specification of how we deal with specification evolution in tools and systems). Specification of the meta-data layer (<component> etc. but also leveraging an future-proof declarative aspect). Focused on one product with a multi-profile strategy. I figure an operational light-profile will emerge and be part of the platform by year-end, but driven more by evolution of extensible meta-info and meta-data as opposed to implementation strategy. I'm also optimistic about some initial back-office technology (remote service discovery, etc.) evolving on top of new Apache projects such as directory, depot, etc.
4. How do I feel about Avalon as an umbrella project vs. a single
product?
I'm strongly opposed to Avalon as an umbrella project - it will fragment the community and slow down massively the process of building the visionary stuff.
I am totally in support of and single product strategy - a necessity that is all about capturing mind share, focus, resources, and forcing us to deal with limitation relative to a single product model - and from within this context - delivering the ultimate Avalon solution.
5. Should there be a formal framework specification?
Formal Avalon Specifications - yes. The work "framework" is little too overloaded.
6. If so, what should it consist of?
* Avalon Spec Specification - generic approach to future-proof specs - runtime strategy * Avalon Component Specification - meta-info - code markup - object model - external forms - runtime contracts - interfaces - semantics * Avalon Meta-Data Specification - system profiling - containment and component directives - external forms - meta-data API - interfaces - semantics
This is what establishes the re-use contract. I think there is more what we can dig into (things like meta-model, packaging, publication and service discovery) but that's all dependent on getting the above three in place - and they are also subjects that will be impacted significantly by spec evolution semantics.
Cheers, Stephen.
* If a clear consensus has not been reached after one week, a vote
will be held. The exact nature of the vote will depend, to a
degree, on the proposal discussions. Foreseeable items include:
- Avalon as an umbrella project vs. a single product
- An effort to define a TCK
- Vote on a specific proposal listed above
I appreciate your patience with me. I hope that I have clarified some ideas here and opened some minds. I may follow up with some further emails exploring the "why's" behind each proposal and a better break down of the various pros and cons. While I'm not certain we can please everyone, I do believe we can come to a common solution and move forward in Avalon without every again worrying about our mission, our vision, or the road ahead together.
Thanks,
--
|------------------------------------------------| | 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]
