avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Merlin's Future with Avalon
Date Fri, 18 Jul 2003 07:42:53 GMT


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:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message