avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [Proposal] Lowest Common Denominator From Paul Hammant (was Re: urban legend ...)
Date Tue, 05 Aug 2003 15:15:19 GMT

Berin wrote;
> Paul Hammant wrote:
>>
>> At some risk, I'd like to reopen this then. Proposal :
>>
>> 1) We strive for a lowest common denominator (LCD) approach with
>> embracing of multiple value-added implementation, which may end up
>> divergent without that being considered a failure.  Thus A-F's Java
>> interfaces are our point of unification.  There is no single
>> container.  There is no unified assembly or configuration meta info
>> specification at  the application level. XML and other.
>>
>> 2) We drop a unified component-level meta info dependancy and
>> configuration design. XML and other.
>>
>> This has been discussed to the tune of a million characters. Let us
>> just  see which of the two above committers have moved on (or not).
>
> With all do respect, Paul, if we do this, then our job is done.  THe
> Avalon CVS is all that we should keep and everything else goes by-by.
>
> The fun stuff would all be done elsewhere.
>
> I fail to get excited about this proposal.  Maybe it's just me.  I gave
> your proposal some more visibility to see if it is just me.

Isn't this very fatalistic?
1. Meta-info model of components are required in the long run. Take the
evolutionary approach and let the container development dictate the
outcome. Stephen's work on the meta-info "break-out" is "Merlin's
requirement", and is probably a good base to start at. At some point you
declare this as "standard of Avalon 4.5", and the containers that wants to
be compliant follow suit.

2. Component packaging is IMVHO a completely missed area of Avalon focus.
AT the present, there is no standardized way to package them, and expose
them through some kind of repository system (perhaps only the through the
Filesystem).

3. Better tools to "wire" components, preferably as far as direct IDE
support of Netbeans and/or Eclipse.

4. Dynamic Components, that are added/removed on the fly, is another
interesting area, where framework level specifications are required.

I am sure there are many more, when the containers are "gathering
experience" and bringing it to the table;
"In  Merlin we have found that ...."
"Interesting, but in Fortress we are inclined to look at that problem
like..."
"Couldn't we consolidate around..."
"Ok let's test that first... Yeah, easy to do that way in Merlin... Wow,
in Fortress too..."

Healthy, evolutionary progress....

And as Paul said, it is not bad that a particular API doesn't evolve
further. Some shark spieces doesn't either!
New APIs to address newly encountered areas of interest.

Positive attitudes, strive forward and not bickering about current states.
Get back to "Release Early, Release Often" and "Develop for Change"
without being tied in with huge chunks of deprecated code.

Niclas



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message