avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: AW: [Proposal] Breaking up Avalon
Date Tue, 19 Nov 2002 12:51:44 GMT

Mauro Talevi wrote:

> Stephen McConnell wrote:
>> I really thing things could go a lot further than that.  If you look 
>> at the solutions that are being addressed by Merlin and Phoenix - 
>> they are different.  Phoenix is much more focussed on the application 
>> deployment scenario.  If you attempt to look at Phoenix as a enbeded 
>> component deployment solution is sucks big time.  If you look at 
>> Merlin it has zero app level features (i.e. Merlin as app-server 
>> solution sucks) - but it really is nice at the component level.  Heck 
>> - putting these solutions together would be brilliant.
> Personally, I think of Phoenix as a app-server - much like Tomcat but 
> for generic apps, not just webapps.
> Its strength  is that it provides an out-of-the-box app container.
> I don't know Merlin- so I can't make any comment on its pros and cons 
> - but as you say Merlin and Phoenix
> have such different aims and target application scenario, then maybe 
> it's best to keep them separate.
> Often, trying to bring together too many orthogonal requirements only 
> results in something that is not as
> effective as two separate apps. 

That makes sense - based on feedback on the user list and priorities I 
have, the appliction of Merlin as an implementation concern mean that it 
becomes totally orthogrinal to the Phoenix objectives. However - we 
still need to take into consideration an area where there is an overlap 
of interests.  Phoenix does coponent assembly and deployment - Merlin as 
well. Ok, Phoenix is the context of stuctured apps - Merlin ios in the 
context of finer-grain componet assembly.  When users want both there is 
a conflict/duplication.  This is most apparent in things like the 
defintion of meta data.  For example, I have a fork of corenwerstone 
that contains supplimentarty meta data that allows the useage of 
Cornerstone components in an embeeded environment (just the the James 
project in some areas).  It's possible today because Merlin supports the 
Phoenix meta modelbut it would be much nicer if that model converged to 
a single solution.  If you really do the analysis - you end up with a 
sceanrio where the Phoenix appl listener model can be repesented as a 
lifecyle extension.  Within the inclusion of meta information for that 
particular feature, we are really close to a comon model.  Just about 
all the rest can be handled in the implemetation.

Cheers, Steve.

> Cheers, Mauro
> -- 
> To unsubscribe, e-mail:   
> <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Stephen J. McConnell

digital products for a global economy

To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>

View raw message