avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: reduction ad unum
Date Fri, 22 Nov 2002 20:52:43 GMT
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.

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.

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?

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

	--- Noel


--
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