avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Re: More on contract strength (was Re: Unifying Vision)
Date Thu, 11 Mar 2004 14:28:12 GMT
Stephen McConnell wrote:
> 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

>> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message