1) To my understanding, Avalon has four higher-level containers: Merlin, Phoenix, ECM & Fortress. Are ECM & Fortress better suited for embedded server solutions?
yes.
Consequently, are Merlin & Phoenix meant to be basis for your stand-alone application servers?
yes, though embedding merlin works perfectly too (AIUI).
2) Why is ECM being replaced by Fortress? Don't we still need a simple & light-wait container/component manager along with sophistications of Fortress?
Fortress is light-weight as well; comparable in size and scope to ECM. In addition, its architecture is a lot better.
3) Would using Fortress, as your container/component manager, exclude wrapping your app up with Merlin or Phoenix?
nope.
3) Avalon's web documentation specifies that components are meant to represent low-level application logic and blocks (implementing services) are to encapsulate higher-level concepts, even at the utility level. Does this mean that a good Avalon development practice requires us to put components (wrapped up by some sort of manager) inside blocks that are, in turn, managed by service manager(s)?
sort-of. In figuring out the terminology, the ServiceManager is not the thing that manages your component. The container manages your component, the ServiceManager is a communication mechanism between container and component.
It is often also perfectly valid (when using fortress or ecm, for example), to drop the concept of "block". Nor do you always need a manager wrapper.
4) Is there a clear distinction between a component manager and service manager?
Their contracts are the same, but ServiceManager is not tied to the Component interface. IE:
public interface ServiceManager
{
/* snip */
public Object lookup( String role ) {
/* snip */instead of
public interface ServiceManager
{
/* snip */
public Component lookup( String role ) {
/* snip */the Component interface was a bad idea :D
5) One of the Avalon developers has recently said that "Avalon is about doing things right not for a deadline". Wouldn't this mean that focusing on a well-crafted kernel and plugable architecture should take precedence over creating more containers and constantly improving things that are to be deprecated?
I think so, yes. The problem is that it is extremely difficult to create a well-crafted kernel and a pluggable architecture that satisfies all usecases. It takes several iterations to 'get it right'.
6) Wouldn't focusing on creating a comprehensive project documentation follow into "doing things right"? Updated and meaningful documentation could not only create a happier Avalon community but also provide a clear mission statement for project developers?
sort-of. The key here is that avalon is developed by volunteers, and most of those volunteers enjoy writing code more than writing documentation. A lot of high quality documentation might make the user community happy, but the developers would certainly not be happy if all they were allowed to do was write documentation :D (btw, everyone is invited to submit new or updated documentation)
Thanks for your help. I hope that I didn't sound like a big complainer.
Complaining is okay...but unless you volunteer to do the work yourself there's no guarantee it will get anyone anywhere :D
cheers,
- LSD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
