Berin Loritsch wrote:
control. There were big conversations to help make it more reasonable in
respects to looking up services. At that time, the concensus is what was
written in the DWA paper. Based on the tools available at that time, the
choice of looking up a service based on the interface name was a natural and
simple solution.
The above is totally understandable with respect to the specification of an implementation - although I have grave doubts about the approach of using a tutorial document as the grounds for a product specification. If fact I would go further and say that using a tutorial document is basically equivalent to not doing the specification.
Keep in mind that the "spec" was in the mailing list and in the minds of the developers. So, was there a formal spec? Not in any traditional sense of it. However, what was in the tutorial was as close to a spec as the Avalon team got at that time. Bear in mind this is history, let's not rewrite it.
The problem came in as we evolved the container code based on these assumptions.
ECM made it a bit easier to use the guidelines by adding some semantics to them that the ECM would handle automatically (in hindsight, it was too much magic).
Lets' drop the "too much magic". In hindsight it was a fork of the common interoperability specification. But wait - there was never a common interoperabily specification - just the spec on a set of artifacts - contract without semantics. In hindsight the problem was the absence of an interoperability specification.
How can there be a "fork of the common interoperability specification" when it did not exist at this time? Remember, this is a history lesson, not trying to prove anything pro or con.
Meanwhile, as time went on, Phoenix experimented with attributes tagged in the source code. Since Phoenix was able to provide assurances without the need for selectors or mapping interface names to lookup values it evolved along those lines. Now Merlin actively discourages mapping lookup values to interface FQCNs.
Not completely correct.
Merlin simply documents the specification by requiring the component to declare explicitly its assumptions concerning the supplied key. This only difference - the completion of the contract by both parties so that there are no ambiguities.
Ok. Merlin documented Phoenix's specification, but did not even attempt to include ECM users in on it at that time. Why? Well because ECM users were using a "Roles" file to handle that meta information and there was a split community. Not because of any diabolical plans (unless you know something I don't). Phoenix went so far as to have a seperate mailing list and it evolved and forked away from what people expected in the main avalond-dev mailing list. When we have an effort build off of what was diverging to begin with, it is no wonder it is worlds different from what many long time avaloners are familiar with.
Fortress came on the scene to help with the transition from needing
interface names for lookup values and selectors, but still supported it due to the need for using existing components.
That is the nutshell view of how we got where we are. Fortress sits between ECM and Phoenix, and Merlin is somewhere past Phoenix.
Here is another view.
Phoenix made very significant progress in actually dealing with the question of the full contract. Merlin went further and filled in a bunch of additional details not addressed in Phoenix, Fortress or ECM concerning the complete contract.
But what Merlin does is not end-game. Its just an example of doing things more completely. There is a lot more that we need to do to provide a complete interoperability specification. And in reality it such a specification must deal with evolution of the specification itself.
I did not address the technical advances made by the efforts, but gave a history lesson from the community standpoint. Take it for what it is. Both Phoenix and Merlin did contribute to our more full understanding today. We would not be where we are without the advances made in either project. However we would not be where we are if we had the ability to plan for and control growth and experimentation. In hindsight there was a lot of trying to "freeze" the spec because of FUD about the future. That is hindsight, which is 20/20. However, we are where we are, and as a community we have to figure out how to move forward.
In a sense, we went from a stronger contract to a weaker one on the key names.
We went from an vague contract to an explicit contract.
Notice the qualification: in respect to key (lookup) names. We traded strength in that contract for a stronger and better contract.
Was this bad? No, because the overall contracts were made stronger due to the meta information.
Forget about meta - the contract was better because the information was actually provided as opposed to implied.
Meta info was the tool used. Am I wrong in that?
<snip type="disparage me to get better positioning"/>
The Avalon Meta package defines the following:
* an immutable descriptor of a component type that declares a service dependencies, context requirements, logging requirements, configuration requirements, parameterization requirements, stage dependencies, and service and extension capability
All this could be done with another tool like Commons Attributes.
* an API that provides simply and convenient access to this information
Matter of opinion, and cannot be proved or disproved by fact. I happen to disagree strongly.
* a set of builders and writers that provide support for the
internalization and externalization of this information
Again, this could be done with another tool like Commons Attributes. IMO even more simply.
* a collection of tools to make the process of generating the
information trivial and totally automated
Again, this could be done with another tool like Commons Attributes.
From this - and before you reply with you standard line, just present your concrete technical arguments about what you think should change - and as you do this, reflect on what is working well - and the requirements for maintaining a released platform that is working really well - taking into consideration real constraints.
Why bother? I am not going to rehash the same arguments over and over. I used this example for a reason. One reason was to show that we have repeatedly failed to embrace new concepts in any shape or form, or leverage existing tools that are just as suited or even better suited for the job.
The contract is with the XML data format, the serialized format, etc. The
information is not stored with the class itself. A better contract is one where we supply the code for the attributes, but use something less restrictive in how to set up and use like Commons Attributes.
This is an implementation detail this is "academic". The important thing that your missing is that there is a object model (the Type) that provides the complete declaration. There is also an XML form that is needed when we are dealing with "real-world" problems that "real-world" clients are addressing.
Look, we disagree here. Instead of rehashing everything, I will be solving real world problems with my real world container that can embrace change while still remaining true to its traditions. I don't like the object model, I think it is heavy and over-engineered for the problem at hand. That is my oppinion. I have always had it. I won't fight you over it anymore.
Sooner of later (or perhaps not at all) your going to figure out that interoperability is *not* about implementation - its about contract, sufficiency and clarity of information, and formats for the exchange of that information. It's not about how you go about implementing the model. Would Avalon Meta be easer to deal with in JDK 1.5 sure - but its totally academic - we are supporting users on JDK 1.3. Are that improvements we can make to the package - sure - I got a big list - but that big list will not break the principal of:
* a complete specification of the requirements of the component type
That's fine.
* backward compatibility
You were talking about moving forward with the specs. It would be easier to not worry about backwards compatibility if it meant that the contracts can be made simpler and easier to enforce. You will find that to be the thing that makes it *really* hard to come up with your spec.
You cannot have backward compatibility and a unifying spec. It can't work. When will you understand that? You have four containers to have backwards compatibility with. How is that going to work when they do not interoperate smoothly now?
You will have to break some minor things to fix some bigger ones. Avalon Meta would be easier to deal with using Commons Attributes, which will support JDK 1.3 on. Yet, Meta is your baby and you are afraid to part with it.
Do you want to really go to the mat with Stephen to add that meta data definition to the Meta package?
If anyone want to go to the mat with Stephen they should really come to grips with the difference between meta-info (an object model specified and implemented under the Avalon Meta package) as opposed to meta-data (an object model specified and implementation as part of the Avalon Composition package). And if they really want to take me out - they should have a good idea of how meta-data combined with meta-info establishes the context for the creation of a manageable and sustainable meta model.
Are your ready?
Why bother? It is clear you have your interests in mind, and not mine. It is clear you *will* not bend even on small points that don't compromise interoperability. I could care less to argue with people who will not even entertain other points of view. It's that simple. And it is that reason I started Dojo. I'm tired of the same old stuff being thrown in my face and trying to work with people who obviously don't want to work with me. Have you "won", Ha! Not even close. I don't want to see Avalon cease but if its future is to have the Golden Gate Bridge when all you need is a plank across the creek, well, count me out. The only reason I am still around is because I have a vested interest in what goes on here.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
