avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: An Avalon Roadmap?
Date Wed, 08 Jan 2003 17:07:47 GMT


Leo Simons wrote:

> Hi gang,
>
> let's get everyone's agendas out on the table and figure out where we 
> all want to take avalon in 2003, and then lets see how much we can get 
> those various directions to converge. Good idea? 


Steve's Agenda
--------------

Context:

  I have an interest in delivering next generation service and
  process management solutions.  Solutions I have been involved
  with all based on Avalon 4. These includes a user-centric
  business model of people, places and things, a minimal PKI
  system (CA, RA, etc.), notification services, domain
  management, adaptive security solutions (driven my some advanced
  meta based systems), a solution cross-enterprise component
  collaboration (also meta based), registration and discovery
  services, web server and web navigation tools, and suite of
  supporting systems extensions, together with the underlying
  component level content here at Avalon (framework, excalibur,
  sandbox).

Ambitions:

  Two abmisions:

  1. Understand open-source (sociology and physiology)
  2. Evolution of a distributed component architecture.

  Ok, the first is a little esoteric but it something I'm
  interested in.  The second is a little more pragmatic and
  related to the work I do here in Paris.

  On the pragmatic side:

  * Avalon 4 is a great starting point.
  * Meta/Assembly/Merlin is addressing real requirements that
    I have today and is instrumental in developing thoughts
    concerning forward looking strategies.
  * A common container platform/architecture is right up high
    on my list of priorities and a necessary ingredient.
  * A common distributed container architecture is where I want
    to go in not so distant future.
  * Delivering what groups like Cocoon (blocks), James (Mailet),
    Xxxxx (Servlet) need is really important to me because it
    provides real grounding - and I do believe that we are
    capable of achieving this.

Issue:

  We don't have an Avalon agenda/roadmap.  We are spending time
  on cycles concerning product release (Cornerstone, Fortress,
  Phoenix) without a clear-cut objective.  I hate this.  If
  we were talking about releasing products in the context of a stated
  Avalon agenda/roadmap then the implications would be more concrete,
  measurable, and qualified and would be easier to map activities in
  the greater Avalon goal.

  I do understand the problem when someone has build something and
  someone else is sending your off-list emails basically saying "hey
  we want to use this but we can't use it until its released". I'm
  sure Berin is getting this sort of thing related to Fortress, I'm
  getting it with the Meta/Assembly/Merlin content.  But in both
  cases, the absence of a agenda/roadmap makes it difficult to
  access things - it also makes it difficult for people to access
  and get involved with the things I've been working on. It also
  makes it difficult for me to understand how Phoenix plays into
  the big picture and how I can contribute.

Roadmap:

  This is most important topic for me.  I really would like to see the
  "Avalon Container Architecture" move ahead in the context of community
  goal - I think there is a start based on the data up on the wiki. Throw
  into this the really great input from users back in December and Leo's
  excellent work on the context process and we are heading onto something
  with substance.

  I'm personally not interested in pursuing a micro Avalon (although the
  factory controller scenario is definitely interesting). To be honest I
  don't see where the collective bandwidth will come from to sustain this
  given other subjects we are grappling with. I do think it is interesting
  to have that interest present but the prior priority is the mainstream
  platform.

  Let's focus, deliver results, and get out press releases - show everyone
  that what we can deliver seriously rocks.

  For me, this means:

  1.  a 4.X strategy

      -  get Fortress released in the context of an established
         agenda and roadmap - why?

         * because this is a rationale ECM close
         * because it can be done in the context of a roadmap
         * because we need back up Berin on this
        
      -  work on a complete embedded component platform in the
         3-4 month timeframe - why

         * because it meets real and immediate A4 requirements
           that are not addressed by anything else in Avalon
         * because I figure that the amount of time it will take
           to get the platform to a stable point that this both
           valuable and tangible for another 1.5 - 2 years
           sustainable scenario, while
         * being sufficiently functional to support A5 concept
           testing and validation and evolution

       - forget about branding, it's not Phoenix, Merlin or
         Fortress - its about a meta-model, a deployment
         architecture, lifecycle strategies, lifestyle policies,
         etc.

  2.  a 5.X strategy

      - clean sheet of paper
      - leveraging what we have learnt (and not so much on
        what we have done)
      - a context in which we can work through getting the
        "Avalon rocks" platform in place
      - sufficient time to do this so the end result carries
        the same sentiments and protection we give to the core
        framework

   And qualified by the following comments:

   The 4.X and 5.X strategy are concurrent.  5X needs a solid 4.X
   platform backing the user community.  But 4.X needs a stop point -
   something close to the convergence of our current container
   suite.

   My feeling is that 4.X container development is about being
   pragmatic and leveraging what we have as opposed to 5.X which
   is a real generation jump from the 4.X mindset.  5.X should deal
   with and should be measured by it's ability to meet evolving
   requirements from Cocoon blocks through to James Mailet. And in the
   process - I would expect to see 5.X features filtering down into
   the 4.X platform and 4.X experience filtering up into the 5.X
   deliverable.

   At the end of the day I would anticipate 5.X seamlessly absorbing
   the 4.X platform content.  No preconceived ideas about dumping code
   or abandoning communities - simply an elegant, advanced, adaptive
   platform capable of meeting cause and fine grained component
   management requirements.

Cheers, Steve.


-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message