Re: Containerkit

Paul Hammant wrote

> Leo Simons wrote:
>
>>>  b) absorbing of containerkit into Phoenix (giving it x.x.phoenix 
>>> packages).
>>
>>
>>
>> Given the speed the "common ground" discussions are taking I think 
>> this is the best compromise. I am a bit concerned about later 
>> backwards compatibility (if the final "common meta setup" we agree 
>> upon deviates a lot from the one currently used in 
>> containerkit/info/phoenix, it'll be a lot of work to get phoenix to 
>> support both). 
>
>
> We're gong for a scrap current (meta-model) design right for uber right?


As far the meta subject is concerned I look at it as a process of 
evolving based on experience, requirements and concensus.  I'm confident 
the what will come out of the process will leverage a lot of we already 
have and I'm also confident that the result will be different to what we 
have now - more of an evolutionary step forward.  I also see this 
closely related to how the the containement architecture unfolds 
(keeping in mind that the meta is a small but intrinsically important 
part of a container solution).

<snip>

>> I'd also like to see some notice in the phoenix documentation that 
>> although the meta materials are stable codewise (and supported as 
>> such), we're not too sure about some aspects yet and thus that there 
>> may be big changes in future versions (as we already know this, users 
>> should know too :D). 
>
>
> I don't see why Phonix has to carry adverts for meta (which it does 
> not use).  Meta is in sandbox right?


I think the reference to "meta" (lowercase) above is in the context of 
"meta-model" development in general (i.e. its not referring to the Meta 
package).

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:[email protected]
http://www.osm.net