avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [VOTE] New Development Direction
Date Tue, 03 Dec 2002 18:54:59 GMT

Just taking care of paperwork - my vote on this is +1 on Avalon 5.

Cheers, Steve.

Stephen McConnell wrote:

>
> Berin:
>
> I think that there is a problem with the subject you are
> requesting a vote on.
>
>  * There is the issue of the evolution of the Avalon
>    component API specification - refining, evolving,
>    based on what we have.  Wether this is 4.3, 5 or
>    6 is not the issue - the issue is identification
>    is problems and resolution of solutions.
>
>  * There is the issue of the container framework.  This
>    does not need 5, 6 or whatever - what we have at the
>    client contract level has only a minimal impact on
>    the objective of a common containement architecture
>    and profile based containers.
>
> If you were to rephrase the question along the lines of
> "are we starting out with a clean sheet of paper" with
> respect to containerment architecture then I'm totally
> with with you.  That process will result in resolution
> and evolution of the avalon framework contract.
>
> Cheers, Steve.
>
>
> Berin Loritsch wrote:
>
>> This is a vote to clarify whether we want to focus all
>> our discussions of the new unified container to Avalon 5
>> (next generation) or Avalon 4.1 (current generation).
>> Here are the implications:
>>
>> Avalon 4.1
>> ----------
>> Current development.  We refine current interfaces so that
>> the contracts are more universal and testable.  This includes
>> the semantics we have surrounding Context and Serviceable.
>> It also means that we can't clean up the cruft.  (deprecated
>> stuff remains deprecated).
>>
>> Avalon 5
>> --------
>> New development/clean slate.  We leverage our experience with
>> lifecycle interfaces to provide a starting point, but we do
>> not limit ourselves to that alone.  We can clean up the cruft,
>> but we must supply a "Compatibility JAR" to allow easy migration
>> from Avalon 4.1 to Avalon 5.  We can also shorten the package
>> names (minor, but sometimes helpful).  It also helps us unify
>> on a new product.
>>
>> If we continue version 4.1 development we don't have the
>> luxury of challenging any of the current lifecycle interfaces
>> or making things just simply easier to use.
>>
>> Implied in either action is that the existing containers continue
>> to live their lives until the new container is complete.
>>
>>
>> Which is it?  Unified Container == Avalon 4.1 or Avalon 5?
>>
>>
>> (Voting to remain open as long as necessary [not less than a
>> week]).
>>
>> Please provide a quick comment why you made your choice (either
>> way).
>>
>> -- 
>> To unsubscribe, e-mail:   
>> <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>> For additional commands, e-mail: 
>> <mailto:avalon-dev-help@jakarta.apache.org>
>>
>>
>>
>>  
>>
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




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


Mime
View raw message