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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
