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.
Stephen, I will clarify exactly what I mean.
I am not saying that Merlin cannot allow new things to be done. That would be like trying to kill Merlin by asfixiation. I am saying that Merlin cannot have a *different* way of doing the *same* thing. For instance, either all containers use the "urn:" notation or none do. All containers have the same core set of metadata or none do. We need to standardize the RULEs, not necessarily the implementations and featuresets.
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.
Stephen, I am not going to start arguing with you on this. I respectfully disagree. Nevertheless, if the spec is insufficient then the spec needs to be upgraded. That is what the community is for.
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
You are completely missing the point. See above for my clarifications. There are different standards used for Merlin than are used for the other Avalon containers for essentially the same thing. Whether we alter Merlin or the containers is something that we need to choose. Divergent means that it deviates from established specification or pattern. In some cases the divergence can be seen as a plus, and in other cases detrimental.
The purpose of this email is to get us focused on what it will take to bring all the containers in line, as well as start the task of making it doable.
So what's your opinion - are you conservative or democrat?
Think of the most conservative person you know (other than me), and I will likely consider him a liberal ;P
Seriously, what does that question have to do with the price of tea in China?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
