Re: reduction ad unum

[Stefano Mazzocchi]

Noel J. Bergman wrote:

Stefano,

I like Berin's proposal of layered containers:
 - reference implementation
 - embeddable
 - standalone
and I would love if they shared code directly rather than having
different implementations of the same interfaces.
So, let's start from here: is anybody against this?

To begin the process, what do you think of Stephen McConnell's recent
postings?  As I understand it, and I expect to be corrected if I am wrong,
he believes that:

   * service management
   * type management
   * profile management
   * appliance management
   * logging management
   * context management
   * configuration management
   * component assembly
   * lifecycle processing
   * lifestyle handling

are fairly mature service facilities that are well enough understood and
developed to support strong common contracts, and considerable common code.
He also mentioned classloader management, containment strategies, and
security policy management as additional areas for consensus, but which he
didn't feel were as well understood.

These could add to the list of existing facilities listed by Peter Donald as
in process for sharing, if not already shared:

   * extension management
   * logging
   * XML Policy
   * classloader management.
   * Type management [the fork problem must be fixed]
   * Configuration validation
   * JMX integration
   * Isolation management (ThreadContext + jprocess)
   * Pooling

I'm not sure why things like pooling aren't taken from Commons, but that's a
matter for a technical discussion, not a process discussion.

Peter further suggested that "compiled interceptor chains" would help to
build "a viable container IMO that satisfies all our needs" and pointed out
three other specific areas:

   * [component info] can be cross container relatively easy.
   * [Component assembly] is likely to be about 70% portable
     between containers
   * [component runtime state] will most likely be completely
     container dependent.

It isn't 100% shared, but it is a starting point.

What concerns me a little with this approach (but that might be only me so feel free to ignore if nobody resonates with this vision) is that we are discussing architectural solutions and not functional requirements.

I would much rather start the discussion from scenarios of use and from the functionality required by all the framework user.

For example, during the cocoon block discussion over at cocoon-dev I'm sure that the perception of the architecture of a container changed a little (at least, Stephen said that he had to think more about the functional needs that cocoon blocks required)

Don't get me wrong: I'm pretty damn sure that you guys have most of the solutions at hand at this point, but I would like to start from "problems" and then drawing solutions, rather than refactoring different solutions and futher abstract them.

I'm not saying it's a bad thing, it's just that I fear that not many people, even on this list, are able to follow the discussion of refactoring between the various containers.

Real life scenarios will make a better way to understand the reason behind an architectural choice. Something that I personally found very hard to get when the Avalon 5 discussions took place.

In another thread, Paul Hammant and Peter Goldstein were discussing issues
over how to add more robust semantic contracts to the Frameworks.  More work
to do, but acceptable points of convergence appeared to be in the offering.

I'm pretty sure that everybody on this list is tired of fighting and cares about Avalon enough to set aside personal issues and work toward a common goal.

Do you believe that these represent a reasonable set of enumerable points
around which the community can agree, pick the easiest ones to start (you
have to start somewhere, might as well start with what you can do easily so
that community behavior begins to build), and go from there?

Yes, why not. But I'm afraid that only a very few will be able to participate.

For example:

> * Type management [the fork problem must be fixed]

that might be perfectly clear to many here, but I don't have any clue about what that means. And this mean that I can't contribute my vision. And no, I don't think this is intentional, it's just that I (and others here) have missed many architectural discussions.

This doesn't mean that you guys have to slow down the process because of me or others that missed a few episodes. Not at all.

But I think it might be more productive, for everybody, to take a step back and restart from the solutions we want to provide to existing needs and problems. At least to avoid the accademic effect that might be coming out of those very deep and abstract architectural refactoring discussions.

Hope you see my point here.

If so, how do you propose that the Avalon community begin to formalize its
roadmap, and use it to marshall its resources?

I would love to see each one of us writing an email where he/she explains the functional needs and the expectation out of Avalon and an Avalon container and the plans to use it.

Avalon is *nothing* by itself. So each one of us has plans on how to build something on it.

Let's put them on the table and start from there.

--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------



--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>