Peter Royal wrote:
On Monday, July 28, 2003, at 11:04 AM, Stephen McConnell wrote:
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.
Can you succinctly list the ramifications?
I'll try!
There is a social implication complicated by a contractual limitation.
The social implications is:
* "it's not I the avalon namespace I don't have to worry about it"
This is complicated by a contractual limitations:
* "the avalon namespace model does not support model extension"
I want to start things off with the social implication, however, let me just note that under the @avalon namespace we do not have any notion or mechanism to declare expansion of that namespace. This means that if something is not inside Avalon namespace - well - it just does not exist in terms of something standard and recognized. But I'll come back to this in more detail.
On social implications: -----------------------
The @avalon.stage tag declares that a component has a deployment phase dependency relative to a container. This means that a container should either fulfill that deployment phase dependency or toss out the component. The @avalon.stage tag does not dictate a mechanisms to a container - it simply declares a deployment criteria.
If we retract the @avalon.stage (and the corresponding @avalon.extension) tags from the Avalon namespace, we are stating that the notions of deployment phase (versus classic runtime phase) notions are concepts that can be ignored. There is dilemma here, because the vote in question does not address the implications. If you remove @avalon.stage from core Avalon - then any component that leverages deployment phase dependencies (i.e. components that fulfill stage execution) will no longer be a valid Avalon components. The implication of this is that a container could be asked to deploy such a component, and unless the component does its own error checking to validate that in fact its lifecycle stages have been executed, we enter the gray zone of unpredictable components. This gray zone is components executing on the assumption that they have been fully deployed. This potential false assumption can lead to failures in security, inconsistency in service delivery behavior, and potential damage by a component simply because it is acting under incorrect assumptions.
The counter argument to this case is that the notion of a lifecycle dependency can be moved to @lifecycle. Socially this will ignored. As soon as we start down the track of multiple compliance levels we will have lost. Containers outside (and quite probably inside) Avalon will ignore @lifecycle because its not part of a "core" @avalon contract. Those containers will not validate components in the same way. Those components and will be running blind.
If we don't do a complete description of container responsibility - they we must do nothing less that revert to container specific solutions @phoenix, @fortress and @merlin.
On contractual limitations --------------------------
As mentioned about - @avalon.stage is not about excalibur-lifecycle. Its about the declaration of a deployment phase dependency. One cannot simply retract this tag from the Avalon namespace without providing a solution. The problem concerns many components that use extensions and their need/requirement to declare that criteria to a container in a consistent fashion. Under an @lifecycle solution - you MUST have a way of declaring within the @avalon namespace, that an @lifecycle is to be including in the component deployment criteria. This is non-trivial.
In my own experience the lifecycle stage model has served to address some key limitations of the Avalon component contract. This is based on experience with stage extensions that use excalibur-lifecycle and others that are totally independent of excalibur-lifecycle. These advantages must not be lost. To assure this we have a choice .. we either recognize the deployment phase dependencies can exist, or we halt this process and go back to the drawing board and come up with a revised specification that addresses component criteria at a more abstract level. I believe that what we have today is complete and consistent. I believe that we will come up with a small but interesting number of different approaches to stage management (including inceptors and event based handlers). I do not believe that this will be contradictory to the @avalon.stage tag. Instead, they will represent different, smatter better solutions to handling the criteria expressed by an @avalon.stage.
I also thing that as we move forward, with experience based largely from work with extensions, we will figure out what we need in terms of tags extension semantics (i.e. how to tell a parser to look beyond @avalon and what to do with the result). Those ideas will have ramifications on tag definitions, meta info, meta data, meta models, and containers. In the meantime, a complete solution (i.e. including the deployment phase dependencies) will provide more than most people will need and everything that Avalon needs.
Summary: --------
* moving out of core means death to the idea of reliable deployment across containers
* an absence of an extension mechanism in @avalon core makes the proposal technically invalid
Now is not the time to throw together an extension mechanisms - the problem is non-trivial and a solution need to grow from common needs, interests and experience. Now is not the time for another divergent split in Avalon - containers that see and contains that don't (i.e. containers that recognize the full criteria and containers that claim Avalon compliance but ignore the reality of what developers are doing using release Avalon product).
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
