You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@d-haven.org> on 2004/03/10 15:37:05 UTC
More on contract strength (was Re: Unifying Vision)
Niclas Hedhman wrote:
> Some people don't like the 'rigidness' of strong contracts and says we will
> limit our choice. Damn right!! It is necessary to limit the choices. BUT, it
> doesn't mean we can't evolve the contracts later, or introduce new contracts.
> That is completely within the scope of strong contracts.
> My previous post lists some of the contractual areas that I can see that we
> need to tighen up, one of them being "Component Requirements Extension
> Specification" which is all about a specification around how to create and
> evolve specifications in a "Future Compatible" way.
>
> The fluffy hippie days are over, time to get organized, time to become
> efficient, and time to serve our users more than our egos.
>
> * Stringent but extendable component contracts in various areas.
> * Leading to self-contained components
> * Leading to remarkable tool support
> * Leading to flourishing number of components.
There is a major difference between rigid and controlled contracts. There is
a major difference between FS and meeting needs. If what you are proposing
isn't so much a dictatorship of contracts but a reasonable set of contracts
that control access points then +1. However, I still use EJBs as an example
of an overspecified product that still only provides marginal compatibility
between containers. You feel like you are in a straight-jacket, but you still
don't have the promise of compatibility on the level that they are advertised.
I am all in favor of *controlled* contracts. They provide a reasonable
foundation to build with, and yet still alow for some amount of flexibility.
No-one on this list has ever advocated complete hippy free-bird approach to
development. I don't think that has ever been a question.
The major question is how tight to make the contracts. To provide a useful
physical analogy, many bolts on an engine are specified to only be torqued
so much. If they are torqued to much (tightened down for our ESL folks),
then the bolt will either break or cause damage to the engine. If they are
not torqued enough, then it will come loose and cause damage to the engine.
When there is a spec that specifies the amount of torque to be applied to a
bolt, you can reasonably change the bolt for something cheaper and less
expensive than the original manufacturer's equipment as long as it can handle
the load. A component contract should be like that. Not too strict (too much
torque) and not too loose (not enough torque).
I think that is where we seem to be talking accross each other. You come off
as sounding like you favor totalitarian contracts when I favor something that
doesn't restrict me too much. The definition of "too much" is different
depending on the contract in question. I tend to find that it isn't so much
the strength of the contract that is inconvenient but where the contract is
drawn.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: More on contract strength (was Re: Unifying Vision)
Posted by Jonathan Hawkes <jh...@adsnm.com>.
> Truthfully there is only one semantic: The key looked up should return
the
> expected component. The differences in the containers is how to map that
> key to the component. With the meta-data, this is one way to close that
> gap.
Should be. But some containers add "special" semantics to certain key names
(eg. selectors). This expectation should be removed.
> As long as you keep your axioms simple and few, then the rest will feel
natural.
> You shouldn't have to have to read 50 pages before you can develop
something
> that can work. It should be natural, and anything outside of that would
feel
> unnatural so you would expect it to not be allowed.
>
> Simple elegance does not mean weak contracts, it means sensible ones.
Agreed. I don't want to have to read anything :) However, confusion should
be cleared up (when necessary) by using more descriptive language in the API
docs. API docs are the only "design" documents I ever want to have to look
at. Honestly, to go beyond that IMHO is just the trademark of some
pretentious, XP-hating software engineer. :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: More on contract strength (was Re: Unifying Vision)
Posted by Berin Loritsch <bl...@d-haven.org>.
Niclas Hedhman wrote:
> On Wednesday 10 March 2004 22:37, Berin Loritsch wrote:
>
>>I am all in favor of *controlled* contracts. They provide a reasonable
>>foundation to build with, and yet still alow for some amount of
>>flexibility. No-one on this list has ever advocated complete hippy
>>free-bird approach to development. I don't think that has ever been a
>>question.
>
> Are you suggesting that the 4 (out of 4 possible) different lookup semantics
> of ServiceManager is a desirable result of 'flexibility'? If so, we are on
> different trains, and will end up at different destinations...
Different lookup semantics? All I am saying is to concentrate on finding
the right contracts, and don't draw lines where it doesn't make sense to.
Truthfully there is only one semantic: The key looked up should return the
expected component. The differences in the containers is how to map that
key to the component. With the meta-data, this is one way to close that
gap.
>>To provide a useful
>>physical analogy, many bolts on an engine are specified to only be torqued
>>so much. If they are torqued to much (tightened down for our ESL folks),
>>then the bolt will either break or cause damage to the engine.
>
> Your analogy (IMHO of course) sux big time. To use the same analogy, we are
> talking about "How big is the hole, plus/minus a particular tolerance?", and
> the answer you want to convey to the users is "Measure it for this particular
> hole (container) and make the bolt (component) fit accordingly."
And then you would be completely missing the point. Bolts come in
pre-determined sizes and threadings (aka the interface). The specs would say
to use a bolt size X threading Y and torque it to Z ft-lbs. If you already
have a component that fits the interface, the only thing you need to know is
if it can fit the contract. No measuring required.
The message I am sending to you, the developer, is to not have your tolerances
so strict that only a select few providers could possibly satisfy it. That
would be an achilles heel.
>>You come
>>off as sounding like you favor totalitarian contracts when I favor
>>something that doesn't restrict me too much.
>
> Well, if buying a M8 bolt will fit an M8 nut, is a totalitarian attitude, YES
> then I fit into that category.
> Let me give you another analogy; My parents bought a house, an old houers,
> where each window was manufactured on-site in accordance to the size of the
> hole that the brick-layers estimated with their eyes as 'reasonable'.
> When we moved there, my parents had a nightmarre trying to match
> "standardized" sizes to each of the 46 windows of different sizes.
>
> Freedom to flex standards only benefits the handicraft guy, and work against
> both consumers and industrialists.
>
> Cheers, I have a train to catch...
Gee, I didn't realize I was a long haired hippy prevert that bucks the system
and hates strong contracts or typing. Seriously, your view point of my stance
is horribly skewed. I had an experience not too different (though less costly),
as I refinished an old dresser. The handles were set with an odd spacing for
the holes. I had to have them special ordered, and my selection of inventory
was very small.
The thing is that there is a common joke in corporate america: "The great thing
about standards is that there are so many to choose from".
As long as you keep your axioms simple and few, then the rest will feel natural.
You shouldn't have to have to read 50 pages before you can develop something
that can work. It should be natural, and anything outside of that would feel
unnatural so you would expect it to not be allowed.
Simple elegance does not mean weak contracts, it means sensible ones.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: More on contract strength (was Re: Unifying Vision)
Posted by Berin Loritsch <bl...@d-haven.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>
>> Stephen McConnell wrote:
>>
>>> Berin Loritsch wrote:
>>>
>>>> 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?
>
>
> Because bothering to understand what exists, why it exists, its
> strengths, weaknesses, features and benefits, is surely a prerequisite
> for product evolution. It applies across the board. Without that
> investment how can we assess the integrity of radical versus progressive
> change?
Honestly, the "Why Bother" comment has to do with the bias I have in past
exchanges with you. You never choose to see any value in someone else's
position, so why bother to expend the energy to try to get you to do it?
If Avalon crams the "Meta" package down the throat of official standard for
Avalon components, then I will be able to support that contract in my
container. No problems. However, I don't like it, never have, and it is
too heavy a solution for a simple problem IMNSHO. So, I have said my piece,
and I will allow you to hash out what Avalon is going to do. Rest assured,
I am not going to worry about the details. Just let me know what they are.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: More on contract strength (was Re: Unifying Vision)
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>> Berin Loritsch wrote:
>>> 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?
Because bothering to understand what exists, why it exists, its
strengths, weaknesses, features and benefits, is surely a prerequisite
for product evolution. It applies across the board. Without that
investment how can we assess the integrity of radical versus progressive
change?
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: More on contract strength (was Re: Unifying Vision)
Posted by Berin Loritsch <bl...@d-haven.org>.
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
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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: More on contract strength (was Re: Unifying Vision)
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Niclas Hedhman wrote:
>
>> On Thursday 11 March 2004 00:09, Niclas Hedhman wrote:
>>
>>> On Wednesday 10 March 2004 22:37, Berin Loritsch wrote:
>>>
>>>> I am all in favor of *controlled* contracts. They provide a reasonable
>>>> foundation to build with, and yet still alow for some amount of
>>>> flexibility. No-one on this list has ever advocated complete hippy
>>>> free-bird approach to development. I don't think that has ever been a
>>>> question.
>>>
>>>
>>> Are you suggesting that the 4 (out of 4 possible) different lookup
>>> semantics of ServiceManager is a desirable result of 'flexibility'?
>>> If so,
>>> we are on different trains, and will end up at different destinations...
>>
>>
>>
>> Since I believe you will answer "No, that was not intended", you may
>> answer the question "So, how did we (even if I was not around, I still
>> consider it a community thingy) end up with it?" You were around and
>> must have observed it happening... And I can for no reason have a clue
>> how it was allowed...
>
>
> Easy answer is that at that time there was no community, much less
> consensus
> on it. Before, it was wide open and anything could map to anything,
> with no
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> A perfect example of what I view to be a bad contract is the Meta
> package in the avalon module.
*sigh*
> It is unnecessarily strict in that any user of the
> package must supply any of the myriad of undocumented contracts that
> Merlin has with it.
Either you don't understand the content of Avalon Meta or, your
attempting to provide misleading information. There are no myriad of
contracts.
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
* an API that provides simply and convenient access to this information
* a set of builders and writers that provide support for the
internalization and externalization of this information
* a collection of tools to make the process of generating the
information trivial and totally automated
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.
> 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.
> You can still provide the Attribute classes to provide strong contracts,
> but you are not locked into only using the meta information
> defined by the meta package. Since you are into tools, there are some
> meta data that would help tools out but not really be useful at runtime.
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
* backward compatibility
> 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?
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: More on contract strength (was Re: Unifying Vision)
Posted by Berin Loritsch <bl...@d-haven.org>.
Niclas Hedhman wrote:
> On Thursday 11 March 2004 00:09, Niclas Hedhman wrote:
>
>>On Wednesday 10 March 2004 22:37, Berin Loritsch wrote:
>>
>>>I am all in favor of *controlled* contracts. They provide a reasonable
>>>foundation to build with, and yet still alow for some amount of
>>>flexibility. No-one on this list has ever advocated complete hippy
>>>free-bird approach to development. I don't think that has ever been a
>>>question.
>>
>>Are you suggesting that the 4 (out of 4 possible) different lookup
>>semantics of ServiceManager is a desirable result of 'flexibility'? If so,
>>we are on different trains, and will end up at different destinations...
>
>
> Since I believe you will answer "No, that was not intended", you may answer
> the question "So, how did we (even if I was not around, I still consider it a
> community thingy) end up with it?" You were around and must have observed it
> happening... And I can for no reason have a clue how it was allowed...
Easy answer is that at that time there was no community, much less consensus
on it. Before, it was wide open and anything could map to anything, with no
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 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).
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. 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.
In a sense, we went from a stronger contract to a weaker one on the key names.
Was this bad? No, because the overall contracts were made stronger due to the
meta information.
A perfect example of what I view to be a bad contract is the Meta package in
the avalon module. It is unnecessarily strict in that any user of the package
must supply any of the myriad of undocumented contracts that Merlin has with it.
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. You can still provide the
Attribute classes to provide strong contracts, but you are not locked into
only using the meta information defined by the meta package. Since you are into
tools, there are some meta data that would help tools out but not really be
useful at runtime. Do you want to really go to the mat with Stephen to add
that meta data definition to the Meta package?
You can still provide strong typing and strong contracts without forcing the
hand on a non-intuitive library. Are we getting closer to the same page here?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: More on contract strength (was Re: Unifying Vision)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
>
> And I can for no reason have a clue how it was allowed...
Fairly simple explanation - although I wasn't around either:
We thought it was the best solution at the moment,
and now we're stuck with it.
Now, what guarantees do you have that your contracts, strict
as they will be, will never be wrong and will stand for ever?
And that's what Berin is talking about when he says "reasonable
contracts". Don't underspecify - because then everyone shoots
off in different directions, and don't overspecify, because then
we're stuck with whatever mistakes went into the spec.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: More on contract strength (was Re: Unifying Vision)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 11 March 2004 00:09, Niclas Hedhman wrote:
> On Wednesday 10 March 2004 22:37, Berin Loritsch wrote:
> > I am all in favor of *controlled* contracts. They provide a reasonable
> > foundation to build with, and yet still alow for some amount of
> > flexibility. No-one on this list has ever advocated complete hippy
> > free-bird approach to development. I don't think that has ever been a
> > question.
>
> Are you suggesting that the 4 (out of 4 possible) different lookup
> semantics of ServiceManager is a desirable result of 'flexibility'? If so,
> we are on different trains, and will end up at different destinations...
Since I believe you will answer "No, that was not intended", you may answer
the question "So, how did we (even if I was not around, I still consider it a
community thingy) end up with it?" You were around and must have observed it
happening... And I can for no reason have a clue how it was allowed...
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: More on contract strength (was Re: Unifying Vision)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 10 March 2004 22:37, Berin Loritsch wrote:
> I am all in favor of *controlled* contracts. They provide a reasonable
> foundation to build with, and yet still alow for some amount of
> flexibility. No-one on this list has ever advocated complete hippy
> free-bird approach to development. I don't think that has ever been a
> question.
Are you suggesting that the 4 (out of 4 possible) different lookup semantics
of ServiceManager is a desirable result of 'flexibility'? If so, we are on
different trains, and will end up at different destinations...
>To provide a useful
> physical analogy, many bolts on an engine are specified to only be torqued
> so much. If they are torqued to much (tightened down for our ESL folks),
> then the bolt will either break or cause damage to the engine.
Your analogy (IMHO of course) sux big time. To use the same analogy, we are
talking about "How big is the hole, plus/minus a particular tolerance?", and
the answer you want to convey to the users is "Measure it for this particular
hole (container) and make the bolt (component) fit accordingly."
> I think that is where we seem to be talking accross each other.
Perhaps.
> You come
> off as sounding like you favor totalitarian contracts when I favor
> something that doesn't restrict me too much.
Well, if buying a M8 bolt will fit an M8 nut, is a totalitarian attitude, YES
then I fit into that category.
Let me give you another analogy; My parents bought a house, an old houers,
where each window was manufactured on-site in accordance to the size of the
hole that the brick-layers estimated with their eyes as 'reasonable'.
When we moved there, my parents had a nightmarre trying to match
"standardized" sizes to each of the 46 windows of different sizes.
Freedom to flex standards only benefits the handicraft guy, and work against
both consumers and industrialists.
Cheers, I have a train to catch...
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org