Leo Simons wrote:
given the decreased likelyhood of the Avalon-Meta package being in broad use across different containers, I suggest we stop referring to it as "standard", because its not.
-1
Without Avalon Meta your ability to establish portable components goes out the window.
A year ago, as a new and raw convert to Avalon, the excitement of developing components and wiring applications together based on the Framework quickly tarnished when I realized that components were *not* portable across containers *despite* the fact that all the containers support the standard framework interfaces.
The fact is that the contract *actually* is more than just an explicit Framework interface contract. It includes meta-information as well. And this concept isn't exclusive to Avalon. I've design framework systems before and learned by experience that this meta-info/data actually becomes an implicit part of the contract, and more disturbing, that is not enforcible at compile time. Who else has designed systems where you pass data through interfaces using a Hashtable?!?! The key structure becomes as much part of the contract as the interfaces.
I'm sure I'm preaching to the choir here, because I'm sure you guys are very aware that a standard meta specification is absolutely critical to any hope of component portability. Regardless of number of eyebrows raisings I've had reading this thread, I'm confident that obvious fact hasn't escaped the core developers here.
... Or has it?
I was excited last summer when I saw the avalon-meta initiative. I thought maybe the glorious day of component portability was within grasp.
Too bad avalon-meta didn't come before the first container was built. But often times, you don't recognize you need something until after you build a few things first. Once you refactor something common out of your system and build a standard around, it is always easiest for new things to be built on the standard. It's the legacy stuff that's a pain in the rear. Making the old stuff conform to the new standard is often difficult and requires great creativity. This is the case for any refactoring job.
What is critically important is component portability. If avalon-meta needs tweaking in order to move Fortress and Phoenix to the standard, then so be it. If it just takes some work and creativity to spin the new spec into the way the legacy stuff works, then so be it.
But it really all depends on the user communities of these legacy containers. Do these products have a vibrant user community that want these containers to continue to grow and evolve? If so, it will be worth the refactoring work to evolve both the container and the avalon-meta package. If these containers are being sunset, then that's another story...
Bottom line, IMO, an avalon-meta standard is critical.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
