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:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
