avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [PROPOSAL] Defining Avalon's Mission
Date Wed, 10 Mar 2004 12:50:40 GMT
J Aaron Farr wrote:
>     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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message