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.
Point 1:
* The meta tags are client contracts. If the client doesn't want to use
extensions, they don't have to worry about it.
* At the current time, all Avalon containers will be required to recognize
it, no matter what namespace it is in.Point 2:
* The avalon namespace model shouldn't *have* to support model extension.
* I personally would prefer model extension to be done in dedicated
namespaces.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.
Not in all cases. There are several examples that I can think of where the extension is more an assembly concern than a component definition concern. There are some extensions that are absolutely a component definition concern. More below.
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.
I disagree. All that needs to be done is the user needs to be made aware that they must ensure that their container supports the @lifecycle extension. Its that simple. So far, two out of three will (i.e. Merlin and Fortress will but Phoenix won't unless someone wants to incorporate it).
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.
You don't know until it happens. If it is ignored, then it is simply additional cruft that would have been ignored in the avalon namespace anyway.
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.
I dislike the container specific namespaces. I prefer function specific namespaces. HOwever this is a topic for future discussion.
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.
Bear in mind that not all extensions are necessarily described in the component definition. In fact, adding aspects to the components to extend their function beyond what they were originally intended will be something that cannot be expressed in an @avalon.stage. In fact it would be pointless as we should not have to recompile a JAR just to add support for an assembly/deployment concern.
As long as the container claims that it is "lifecycle" extension compliant, the component can expect to work without problems. There are several ways of accomplishing this, but for the short term it will be an informal contract.
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.
As I recently discovered in talking to Stefano about adaptive caching, our own experience can be very misleading. Just because we see something one way does not mean that it holds true in all situations. I believe the all or nothing argument does not hold. Think big but start small. To be honest, the stage and extension tags are the least understood of all of the tags proposed. At least to me it is clear what everything else does, and how it applies to pure Avalon components. The stage and extension tags are not so clear, but I am willing to learn. Forcing all users to be aware of them increases the learning curve for Avalon. I am against that. By placing them in a separate namespace, we give the user a chance to grasp things in chunks. It is a very useful tool.
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.
All these can be done -- even when the extension tags are in a separate namespace. So, I believe your arguments are not as strong as you believe.
Summary: --------
* moving out of core means death to the idea of reliable deployment across containers
I don't see that at all. Moving out of core means we need to learn how to deal with non-core namespaces in a predictable and scalable manner. Since there is only one additional proposed standard namespace, we can start with the simplest thing: documentation. Later we can address more exciting concepts.
* an absence of an extension mechanism in @avalon core makes the proposal technically invalid
Again, I don't see this at all. How can it be technically invalid? We are talking about extensions. Extensions are not core to Avalon, but they should be recognized. We can move from just one namespace to more than one, and be able to work with them all.
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).
How is this different from what we have now? Essentially what will happen is that we will have containers that do, and do so consistently (unlike now), and a container that doesn't. However that container will be able to recognize the components it can't handle.
Is there a problem with that?
Also, do not confuse the proposal of namespace with an immediate proposal for container extension mechanisms. The problem is non-trivial, and your arguments give more and more credence to allowing us to grow the solution in a namespace outside of the core Avalon one.
So far the only arguments I have seen don't yeild the vote invalid.
Cheers, Steve.
--
"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]
