-----Original Message----- From: Stephen McConnell [mailto:[EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
