avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [ANTI-VOTE] Lifecycle Extension Tags
Date Mon, 28 Jul 2003 16:04:36 GMT
Farr, Aaron wrote:

> 
>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Do they understand what they are voting for?  My guess is that they will
>>assume the very simplistic line from Berin that this is about a
>>namespace.  They will not take into account the ramifications.  They
>>probably will not appreciate that this is a divisive point in terms of
>>the avalon component model. They will probably not appreciate that it
>>introduces a separation at the core of Avalon and from that separation
>>there will eternally be those that do and those that don't.
>>
>>Steve.
> 
> 
> Just to make sure I understand what we're voting on:
> 
> @avalon.extension  vs  @lifecycle.extension
> 
> As others have pointed out, this at first glance appears just to be a naming
> convention. It doesn't necessarily change the functionality or code.
> 
> So Stephen's objections are on the 'ramifications', which I believe is this:
> 
> @lifecycle.extension implies it is not part of the core Avalon contract and
> thus optional for containers to implement.  This leads to further
> discrepancies between component deployment procedures for containers.
> 
> My take:
> 
> I certainly hope that the current implementation of lifecycle and stage
> extensions is just the beginning.  I believe there are a number of
> enhancements which can be made.  Thus considering that there's room to grow
> and the current code and contracts may likely change, the argument to
> exclude it from the "core" avalon namespace (even if only temporarily) makes
> sense to me.

Right.  It is my position that we should manage these things in unieque
namespaces for function points.  That way they can be free to explore things,
and developers will be aware that only containers which advertise support
for the namespace they are using will be able to run their components.

> 
> That said, it is certainly frustrating from an Avalon user point of view to
> find that lifecycle extensions are not available in Phoenix and that the
> implementation in Merlin and Fortress is slightly different.  A standard
> container extension mechanism is, IMHO, sorely needed.  Therefore, just
> because @lifecycle is 'optional' for component developers to use, it
> shouldn't be ignored by container developers.  Even if full support isn't
> provided, acknowledgement of the feature and graceful handling should be.
> 

That is my intention.  TO have Merlin and Fortress handle extensions
identically.  Phoenix does not have to provide support for it.  THere are
other issues that surround the whole extension concept, none of which
are affected by what name is used to solve those issues.

> I'd like to hear if Stephen can clarify if the ramifications are anything
> more than I have mentioned.

As I would.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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


Mime
View raw message