> > So there is an ample supply of examples of projects with clean, similar, > > pluggable architectures, yet you feel it is impossible to extract the > > common ground between them? > > Because as soon as you start to define the interface to server plugins rather > than client contracts you start making tradeoffs.
true. The main tradoff is one of portability vs "feature flexibility". What muddies the waters a bit is that the proposed server plugins are part of the client contract: if a client can specify a component requires support for lifecycle extension X, there must also be a way to actually specify lifecycle extension X. > Compare TC3 vs TC4s notion > of pluggable interceptors - which is "better"? TC3 is better in some > situations (easier to use, manage and develope, especially when there is > large numbers of intersection points for a particular concern) and TC4 is > better in other situations (potentially better performing, uses indirection > to allow non-linear chains). > > So tell me? Which in your wisdom is better? In "my wisdom", current proposals are approaching a point where the feature set, complexity, etc, is similar to the one the avalon lifecycle propagates. Sure, our lifecycle setup is not the fastest, nor is it the most flexible, or manageable. The one killer feature of the avalon lifecycle is that it is common ground (the other ones being that it is simple, stable, documented, supported). It has been shown that there is need for additional non-standard lifecycle stages to <insert requirment here> write some components. To keep these components portable across containers, the code that supports the extension should also be portable across containers. To make that happen we indeed need to make sacrifices, mainly feature flexibility. > ANd would you mandate that it be > added into all containers or that containers could not implement it using > alternative strategies? nah. It just seems to me that "the most simple solution that could possibly work, in 90% of cases" would be nice to have in the framework. The same arguments are mostly true for other potential parts of the framework (like a common metadata model): there will always be alternative strategies that have definite advantages in some use cases, but the benefit of common ground and reusability in 90% of cases outweighs the downside. It doesn't matter whether such a meta model or lifecycle extension support is dubbed part of avalon framework or if it is called "framework++", as long as we as a project choose as much of a common solution as is possible. It just doesn't seem "wise" to have competing "frameworks" inside the same project. But hey, apparantly that's just "me" =) cheers, - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
