Niclas Hedhman wrote:
On Tuesday 09 March 2004 13:16, Stephen McConnell wrote:

My thoughts for the day.


<snip content="interesting read" />

But I would like to highlight that there is an alternate way to go about these concerns;

The current approach is a lot about converging the existing container implementations and shoe-horn in the 'behaviour' of Fortress and ECM into Merlin.

Agree - but for social reasons - not technical.


One could ignore this for a moment, and accept that the containers are here now, and will not disappear in the near-future, and instead of concentrating on a single container, we start to tighten up the "Component Contracts" instead.


Yes. I think its a viable strategy.


We all know that there are endless holes in the contracts and semantics, which have led to the diverged containers.

But I guess that the 'Flexibility Syndrome Camp' is quick to defend the loose contracts as a "feature". If so, I would like to buy these individuals a one-way ticket to Pico, since Avalon is not about (IMSO) 'class==component', such granularity is too fine and is like Integrated Circuits equals transistor.


I figure most of the tourist already have tickets.
We can move on with confidence.


As we tighten the contracts, we have the choice to implement these in the existing containers, on the basis of OSS. Someone has the itch, they fix it, otherwise it remains unresolved.

OK .. classic approach.


I also strongly recommend that the contract discussion is done without peeking into the container solutions that exists.

And on the other hand there is the value of validating contract semantics against a reference implementation. I like that notion.


I have a whole lot of issues at this end, I would like to "tighten", such as;

Component Type Specification

OK.


Component Instance Identification Specification

New territory for avalon but this is in the realm of managable stuff.


Component Dependency Specification

Atructural is in place but I figure you thinking about the availability contract - no?


Component Packaging Specification

Mre braincells need to die before this is closed.


Component Requirements Extension Specification

Can you explain this one in more detail?


Cheers, Stephen.


--


|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/merlin/distributions/latest    |
|------------------------------------------------|

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to