Re: [PROPOSAL] lifecycle release

Stephen McConnell <[email protected]>
Newsgroups gmane.comp.jakarta.avalon.phoenix.devel
Message-ID <[email protected]>

Peter Donald wrote:

>On Wed, 12 Mar 2003 03:49, Stephen McConnell wrote:
>  
>
>>  * that the package be migrated from the avalon-sandbox
>>    CVS to the avalon CVS as a separate project along-side
>>    the avalon framework
>>
>
>-1 as it does not belong at same level as framework.
>

Pete:

Given the interfaces in the Avalon framework and there to
provide the patterns and contracts of interaction between a
component and a container, and given that this is not proposed
as part of the framework - but simply as the interfaces
defining contract extension, could you perhaps illuminate us
as to where you believe the package fits and the reasons for
your assertion.

>
>
>>  * the release of the avalon-lifecycle package shall be
>>    considered as an "optional" extension to the framework
>>    contracts
>>    
>>
>
>-1 
>

Shall I presume that you -1 is that the extensions should not be
considered optional?  In which case can I assume that you would
prefer that this is a mandatory requirement on containers?  If so,
I would just like to not my personal appreciation for you change in
heart.  It's encouraging to see you take a positive attitude to the
development of others. Even so, I still this should remain an
optional requirement with respect to containment compliance.

>
>It is the same approach that has been done before and failed and 
>can't cleanly produce some aspects like delayed activation, 
>passivation, persistence, transaction demarcation, bifuricating 
>interception etc.
>

Could you please expand on the point you raised above.  My own
experience has shown that the interfaces are sufficiently general
to provide solutions to several of the above areas.  Perhaps you
are confusing the current work with something that was done before
(that I am not aware of).  I'm finding it difficult to understand
why a component provided support for some aspect of a lifecycle
can be implemented using the interfaces in question.  Is there, in
your opinion, some characteristic of the interfaces that inhibit
implementation of any of the above - or were these just random
examples?

I would be really interested in your reply because I'm currently
using extensions across several areas you mentioned and finding
the overall approach *really* functional.  Obviously, I must be
doing something wrong.

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:[email protected]
http://www.osm.net
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.