When I posted my questionaire, I got back a handful of responses from Berin,
Stephen, Peter Royal, and Leo Sutic.  Here are the points of agreement
related to the containers.  It seems to me that when you look at the
technology, that there is a great deal of common ground.

Berin and Stephen, for example, mention almost EXACTLY the same technical
points.

I don't know what it will take to get you to look at where you agree, but
the potential here is quite good.

And with the J2EE project starting, Avalon has a finite window to get its
act together and contribute.  I beseech you guys to go splash some cold
water on, look at where you agree, and start working on those points.

If Stephen agrees to work with everyone to implement all of the below items
in the Merlin core, does that satisfy everyone's technical issues?

        --- Noel

------------------------------------------------------------
   3. Are there concepts from Fortress that should be brought
      into the new code base?
      Don't know [ ]
      Yes        [X]
      No         [ ]
      Please elaborate IN BRIEF:

Berin:
* Fortress provides mechanisms to help ECM users move up.  We should not
lose
   that.
* Asyncronous management is something that should be incorporated, even if
it
   is done as a container extension.
* The BCEL proxy generator needs to be improved and brought forward.

Leo:
 + Backward compatibility, ease of understanding (despite my previous
moans).
 + The concept of hierarchical containers.

Peter:
* async init
* easy nestability
* seda-style handlings

Stephen:
* asynchronous component management
* experience re. ECM legacy

------------------------------------------------------------
   5. Are there concepts from Merlin that should be brought
      into the new code base?
      Don't know [ ]
      Yes        [X]
      No         [ ]
      Please elaborate IN BRIEF:

Berin:
* Merlin has a more managment focused view of things.
* The Auto-Assembly feature helps make things simpler.

Leo:
 + High modularity.

Peter:
* ability to aggregate blocks into a single block

Stephen:
* meta-model
* auto-assembly semantics
* composition semantics

------------------------------------------------------------
   6. Are there concepts from Phoenix that should be brought
      into the new code base?
      Don't know [ ]
      Yes        [X]
      No         [ ]
      Please elaborate IN BRIEF:

Berin:
* JMX integration
* Configuration validation

Leo:
 + Simplicity. I am starting to like the idea that each block is a
singleton,
   for example. It appears very easy to grasp.

Peter:
* jmx mgmt
* config validation
* sar-file format

Stephen:
* security policy framework
* configuration validation


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

Reply via email to