Nicola Ken Barozzi wrote:
Stephen McConnell wrote, On 17/07/2003 3.37:
...
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?
Bullshit, Stephen. You are just generating negative energy, sit down a minute and think of it. It's *not* about how to remove "divergent" things, it's about how to *integrate* them.
Look, I agree with your 100% All of the "divergency" rubbish it's just plain bullshit. The real important thing here is thinking, ideas and effort that is going into the issues the deal with a standard Avalon containment platform.
Berin said:
"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. "
To make the same component run in two different containers, you have three options:
1 - make the featureful one degrade - which is out of question 2 - make components require a specific container - you know it's not best 3 - make the other container upgrade to the new features, or even better make the two integrate into one that has the best of both
Merlin has cool features? Cool! When will it become *the* Avalon container? What is missing for it to become so? What does Fortress have that cannot and/or will not put into Merlin?
There are a bunch of things that need to be addressed as part of the overall Avalon containment architecture. I raised most of these on the PMC thread concerning Fortress deprication. I'll repeat those points here so that everyone has a picture of the issues/scope/whatever-you-want-to-call-it.
[from PMC thread on the same subject]
Fortress uses a different meta-info format and a different meta-data model to Merlin. Meta-info management can be handled via Fortress specific tools that generate standard meta-info from Fortress specific data (e.g. roles files, @x-avalon stuff, etc.). The same could be done at the meta-data layer, however, I don't think we are ready for that just yet. I am currently working on the seperation of meta-data management from assembly semantics - when that's complete then we have a realistic framework for establishing a common meta-data model. This would enable the potential deprication of container-specific meta-data in Merlin, Fortress and Phoenix. The differences are then norrowed down to assembly and deployment semantics. Here things get a little fuzzy - Fortress tools include assembly logic at build time (by checking published services against dependencies) related to a single deployment unit (jar file) whereas Merlin assembly validation takes into account multiple deployment units. I.e. there are some open questions here. As far as deployment is concerned, there is the long standing question of the semantics related to service lookup and the use of selectors. The ROLE/Selector approach used in ECM/Fortress breaks the pridictive assembly semantics used in Merlin (in Merlin you have to declare a depedency on a selector if you want a selector). There are other issues, but I think I've covered the main points here.
Bottom line is that I don't think we should try to have Merlin deprecating Fortress - instead I think we have Fortress deprecating things progressively relative to a standard containment architecture. The difference is that Fortress would continue to exist to handle the delta between what is established as standard, and what is specific to the ECM legacy.
Basically I envisage a future in which the internals of Merlin are changing, evolving and adapting as we move towards the "perfect" solution. I should point out that I think that *release* should not be interprited as an *we-have-to-maintain-Merlin-API-as-is*. Instead - the questions of what *release* actually means should discussed in a lot more detail (and on the dev list - not here). In particular, we need a release plan that outlines what aspects are volotile, what aspects are not. As an example, the assembly package APIs are thing that I think can be improved (if fact I know they can be improved) and I would not suggest coding against them at this time - however, writting deployment descriptors is another story - XML deployment descriptors need to be stable because these are the main interaction point (and everything to-date suggests that this is readily achievable and maintainable).
Cheers, Steve.
--
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]
