On Mon, 2003-07-21 at 21:30, Stephen McConnell wrote:
I'm not keen on shfting this outside of the @avalon namspace because its not different to a @avalon.dependency or @avalon.context - they all relate to lifecycle fulfilment.
Is the issue with @avalon namespace that it should be reserved for only those tags/features which every container supports? ie- Phoenix doesn't have lifecycle extensions yet therefore @avalon.stage should be @lifecycle.stage (or whatever)? Or is it because lifecycle extensions are part of excalibur and not framework?
Just trying to understand what and why we want to reserve the @avalon namespace for. I suppose this is more a question for Berin.
I want to let us allow for arbitrary meta-information which will be used for extension points. For example, support for Lifecycle Extensions as it is currently defined can be put into a container extensions (Appliance in Merlin speak), and that set of information would be available for that container extension.
That way we can easily expand upon the core of Avalon's features, and easily add support for these lifecycle extensions uniformly accross all containers. At least this is my current train of thought. Esp. since we will have to track the @mx-*** management tags as a container extension as well. If we define the mechanisms to do that, all is well.
Not sure how much I like this, but it works. Another alternative would be a set of tags like:
@avalon.dependency.attribute name="color" value="red"
But I'm not sure if I like that any better.
It requires more thinking.
--
"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]
