Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
Message-ID: <3F17CB7C.205@apache.org>
Date: Fri, 18 Jul 2003 12:27:08 +0200
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030529
MIME-Version: 1.0
To: Avalon Developers List <dev@avalon.apache.org>
Subject: Re: Merlin's Future with Avalon
References: <3F15B242.8070402@apache.org> <3F15FDC6.60805@apache.org>
 <bf5m8q$5n3$1@main.gmane.org> <3F17A4FD.1020902@apache.org>
 <bf8d9l$eqq$1@main.gmane.org>
In-Reply-To: <bf8d9l$eqq$1@main.gmane.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit


Nicola Ken Barozzi wrote:

>
> Stephen McConnell wrote, On 18/07/2003 9.42:
>
> ...
>
>> 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. 
>
>
> Ok, let me try and rephrase in a more succing way what you are saying: 
> ;-P
>
> 1 Merlin/the evolution of it, will be the next Avalon container 


Maybe, maybe not - if this process foldes out how I would like to see it 
fold out - the subject of which container becomes totally academic 
because everthing is hitting the same back-end API.

>
> 2 Fortress will not go away because it will deal with legacy components 


Yep.

>
> 3 Merlin needs milestone releases to get more feedback 


There are other people here who want to get involved in its 
development/evolution. Getting releases out (similar to the Maven 
approach) provides binary drop-points, which in turn provide greater 
flexibity for people to jump in and do stuff inside Merlin (JMX, JNDI, 
Service Selection, distribution, etc.) against the CVS and greater 
opportunity for people to lock in against binary relases - from this 
comes more feedback and participation.

>
>
> I agree with 1, 2. 


Not with (3) ?

> I'd add another point: to become (1) Merlin must adopt common standard 
> contacts, which it currently does not always do, as Berin *correctly* 
> pointed out (hence the "divergent" bad work that got you more 
> concerned than IMHO was in the original intentions).


Let's not repeat the same bad habits. If there is something "divergent" 
then say what it is. I think it is time to drop this rather feeble line 
of insinuation. If there is something you (or Berin) want to address 
then get to the point and say it - because neither of you have managed 
to articulate anything concrete. If its just there to create a negative 
context then ask yourself the question - why do you think it is 
necessary to do that? I'm confident both you and Berin will get past the 
point of having to having to cast dispersions - but maybe is a chair 
thing and beyond your respective control ;-).

As to you question concerning "what does Fortress provide as legacy that 
Merlin will not provide and why". There are lots of options and I'm not 
about to forecast which is best. Fortress is light-weight - lighter than 
Merlin. There are open questions about how much Fortress should include 
from a common containment platform - the choice between lightweight as 
opposed to feature-rich. But this kind of question is academic. If we do 
things well with respect to containment API, much of this should be 
configurable (including things like selection of the semantic 
assumptions). Think of it like this - you run up your container in 
accordance with a configuration that suites the deployment context you 
want to establish. And when someone asks you which container your using 
- you just look at them with a expression that suggests you don't 
understand � you think about for a moment - then you twig - and you 
answer - Avalon.

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