Berin Loritsch wrote:
I hope this is not as ominous as it sounds, but I want to get a feel for
the community on the whole Fortress/Merlin/Phoenix scenario. We currently
have two officially released and supported containers: Fortress and Phoenix.
Both have enjoyed a variety of eyes on the projects, and increased exposure
due to their release status. Now Merlin is nearing the point where it would
like the same benefits of Fortress and Phoenix.
Before I can be OK with that, we need to ensure that all user components
are defined consistently across all containers. The meta API separated
out is a step in that direction. We need to be assured that the same
component used in Merlin will continue to function in Fortress, and vice
versa.
Berin:
If I take your "before I can be OK with that" statement literally, I should point out to you that there are things in Merlin that are just not possible in other containers. These features (some of which have been recently exposed by Vinay in his post concerning custom service attributes) are beyond classic Avalon - they go into the area of distributed service management. I am personally really interested in this area and I see lots of adventures in this realm - realized and delivered through the Merlin platform - as not necessarily compliant nor consistent with existing Avalon containers - in fact these very features are pushing beyond the "accepted" envelope.
Is that a good thing - YES.
To that end, we need to focus on the AMTAGS proposal and the Context
clarifications. Currently, there is a similarity in some of the component
definitions between Phoenix and Fortress, with Merlin being divergent in
these areas.
Slow down a moment - your providing some misleading information here. The AMTAGS spec as it stands today is simply insufficient with respect to both Merlin and Phoenix. The work going on under the Avalon Meta is addressing a complete model - but as you are aware, "AMTAGS" do not include a declaration of a version. With consideration of this the revision to AMTAGS in the process of development is addresses a complete solution. That revision is not yet complete as work still remains to be done with respect to Phoenix requirements. To be very clear - neither Phoenix nor Merlin support AMTAGS because AMTAGS are woefully insufficient to express a complete component contract.
We cannot have Melin be divergent. We need one spec to drive the user
expectations.
One must be careful in how one positions something as divergent.
Which of the following existing and divergent characteristics within Merlin would you like to eliminate?
1. ability to provide a complete meta-info model
2. ability to incorporate legacy Avalon component models
3. ability to incorporate non-Avalon component models
4. ability to separate deployment versus runtime dependencies
5. ability to provide meta-data driven context creation
6. ability to support context casting (e.g. BlockContext)
7. ability to support alternative contextualization strategies (e.g. Servlet.getContext())
8. ability to support distributed component semantics
9. ability to auto-assemble and de-assemble components
Beyond that, I have nothing against Merlin. It solves some user needs, otherwise it would not have been written. I think with more eyes on it, the internals will likely be improved without breaking the client's code.
I would go further than the assertion that it "solves some users needs". What Merlin is about is pushing the envelope on what containment is all about. It's a complex platform that is very adaptive. Most importantly - it is a platform that is forcing this community to address a bunch of issues. It forcing us to come to terms with the notion of "portability", "interoperability" and in due-course "distribution". Merlin is an adventure - even more important - Merlin will continue to push the envelope - it will (if I have anything to do with it) challenge accepting thinking, go further and more courageously than any container has gone before (umm, sounds like Star Trek - but that kind of makes sense - its about going way beyond - into things we haven't solved).
I think this is a good thing!
So what's your opinion - are you conservative or democrat?
Cheers, Steve.
The all important question is what is the developer interest in this container? Who else is willing to put their eyes on it and time to maintain it?
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
