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.
The proposal as I understood it means that we live with Avalon Framework and that is it. SO it doesn't change. I have no problems with that.
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).
I can't seem to get enough interested people to attack this area.
3. Better tools to "wire" components, preferably as far as direct IDE support of Netbeans and/or Eclipse.
and IDEA. It would be great, but we only have so many developers.
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 ...."
That would be nice to hear.
"Couldn't we consolidate around..."
I attempted that and got called a control freak.
"Ok let's test that first... Yeah, easy to do that way in Merlin... Wow, in Fortress too..."
It was partly done with the extensions interfaces. It fell apart when talking about the meta info.
Healthy, evolutionary progress....
Its great on paper, but every time we try to merge on ideas it falls apart. I need evidence that this is going to change before I can get behind this.
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.
Yes, but those APIs would be outside the realm of Avalon because we would have stopped with Framework.
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.
We have to undo what was done in the past--we have huge chunks of deprecated code. So what to do now.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
