avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: reduction ad unum
Date Sat, 23 Nov 2002 02:05:04 GMT
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                               <stefano@apache.org>
--------------------------------------------------------------------



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