Stefano Mazzocchi wrote:
>Hmmm, tell me: which version of Avalon are you guys implementing? Where >is the line that separates "framework" from "implementations"? > >So, the real question should be: > > when should Cocoon use a component container based on the design >principles of the next version of Avalon? > >Answer this. > Hi Stafano: As a author of one of those new-fangled containers I thought I'd put together one or two comments concerning the relationship between containers, Avalon 4, Avalon 5 (based on your defintion) and a couple of Cocoon related observations. Where Cocoon is today: ---------------------- There is a *very* big difference between an active lookup (ECM, Fortress) verus a scoped lookup (Merlin, Phoneix) - two different models that have existed in the Avalon community for a long time now. Based on the Avalon 4 spec for a component or service manager, the role key is determined by the implementation (i.e. specification of lookup semantics are minimal). In terms of project like Cocoon, a pure Avalon model would ensure that your client components are interacting with a container through things like service and component managers - they are NOT interacting with the container. But in reality Cocoon is based on ECM and ECM blurs the distinction between the manager and container. Cocoon isn't strict Avalon - its Avalon + ECM - a.k.a. Avalon 4 + an active lookup implementation policy + ECM semantics + ECM role management semantics (which is not a perfect world). Avalon 4 versus 5 ----------------- I like your distinction between A4 and A5 (noteably the question of marker interfaces). Its the kind of defintion that makes me feel a lot more comfortable about a possible emergence of A5 (if and when). Following along this line of thinking, its perfectly reasonable to envisage the introduction of things like a formal seperation of lookup semantics, leading to the eliminating of the inconsitencies that exist today in the Avalon 4 specification. Secondly, it provides a clean defintion of what backward compatability would mean realtive to Avalon 5 in a way that has not been well articulted todate. On containment strategies: ---------------------------- In that other email I suggested something along the lines of a Cocoon subproject that explores the internal "container" achitecture needed for Cocoon - because when you get inside Cocoon it looks like, smells like, and feels like a container. But this does not mean that these aspects should be exposed to client components. The Avalon 4 model provides the component and service manager (and those other assorted things like configuration, parameters, context etc.) as the contract towards a client - and the client exposes marker interfaces as its defintion of itself towards the container - but none of this dictates what the container is, or how it fuctions with respect to compliance with Avalon 4 or 5. For example, a Cocoon core container could be build using an advanced meta-driven container that provided the services required by any Avalon 4 (or 5) based component. Personally I'm not looking at this as a migration strategy - instead, I looking at this is a 100% compatible engineering evolution - the development of a a Cocoon 3.x core containment architecture that replaces the ECM based architecture and delivers totally seamless support for components as they exist today (including all of those implied semantics). Does that make sense? Cheers, Steve. -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
