Re: Containerkit

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