Bennett, Timothy (JIS/Applications) wrote:
-----Original Message-----
From: Farr, Aaron [mailto:[EMAIL PROTECTED]
...And here is the thing that some of us can't seem to grasp... What does it mean to be Avalon-compliant? It is NOT merely compliant with the framework API. The MAJOR issue IMO is that if I (or any Avalon user) writes a Avalon component, then I expect it drop seemlessly into ANY *Avalon-compliant* container and it work straight-up without any modifications. For that to happen, Avalon-compliancy must encompass more than just framework compatibility. It must include standards for meta and such.
The problem is, as we should all know by now, that there has not been any really good definition of Avalon compliance. We are working to fix that. But that doesn't mean we should hide the old documentation or tell developers who have been using Avalon for longer than Merlin existed that we're just going to forget about them forever.
I'm not saying we need to continue to support all these old semantics. I'm just saying we should document them. Heck, I'm not even saying "we", I'm saying "I" will document them and the documentation belongs here in Avalon.
The reason we have a new single platform focus, a new web site, and Excalibur/Fortress promoted as a TLP is so that we can make Avalon-compliancy an eventual reality, with Avalon-compliancy meaning component drop-in execution across Avalon-compliant containers.
I agree, but that doesn't mean we can sweep our legacy under a rug and hide it. There are users of Excalibur, Fortress, Plexus, Loom and others who will come to Avalon looking for older framework documentation. I plan on providing it to them and clarifying what it means (meant) to be an Avalon container for the various framework releases.
jaaron
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
