Paul Hammant wrote:
Folks,
This package is now in avalon-sandbox. Given it is used in Phoenix, has code that was refactored from Phoenix, I think it is best not to mark this package with the 'alpha' status that sandbox affords.
I'd like to see how people feel about ...
a) removal of containerkit fr om sandbox to some place more fitting
Hi Paul:
If you scoping containerkit outside of Phoenix then avalon-sandbox is totally appropriate. Current Phoenix demands on containerkit are minimal and does not consititute validation of the API. More to the point - the recent process of unfolding "Context" has introduced a lot of user content that has a direct impact on the meta model solutions. The context issues and current direction have already created potential requirements for evolving containerkit (and the other avalon-sandbox/meta package). I expect this process to continue and eventually address some meta-issues such as the real needs for extendable meta solutions, the need to break the distinction of context and service - and a bunch of other micro things that only come up when you get into more complex application scenarios. Most importantly, the meta area is still fair game for evolution and development - and as such avalon-sandbox is where that should happen.
or
b) absorbing of containerkit into Phoenix (giving it x.x.phoenix packages).
This is probably the easiest option - although there is a downside. It easiest because containerkit code is inside Phoenix and a little reshuffling will not take much time. It's problamatic in the longer term because I think containerkit will be transient as we move forward on a common meta solution. This means that containerkit can be viewed as an implementation mechanisms for the current Phoenix descriptors. I would not like to see Phoenix meta descriptors updated in a release to correspond to containerkit DTD - that would simply complicate things unecessarily. The upside of absorbing is that the machinery inside Phoenix will at least be closer to overall meta direction - and that's a good thing.
Thoughts gentlemen (and lurking ladies) please...
Something to keep in mind is that containerkit has some chrome to plunder - but in terms of its role as the Avalon meta model - frankly - no way. Why? Becuase there is so much discussion needed on this area. It does not matter if continerkit is good, bad, or whatever. What does matter is that an avalon meta solution evolves based on progressive understanding and input from developers and users.
+1 on moving containerkit to Phoenix in the context of a current Phoenix
DTD implementation mechanism
-0 on evolving Phoenix to propergate the containerkit DTD
-1 on pushing containerkit up as a seperate released package
Cheers, Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
