Leo Simons wrote:
>>>I need it now and are are going to finalize the version in
>>>containerkit now. Phoenix and myrmidon have already been converted
>>>across to containerkit and I have been playing with fortress to get it
>>>to do the same.
>>>
>>>
>>This is bad move if we want to try and a build a common metamodel.
>>
>>
>
>hmm. There is not even an alpha release of containerkit yet, and
>myrmidon and phoenix are alpha software, too. I'd say it'd be really bad
>to have beta software depend on pre-alpha stuff, but alpha on pre-alpha
>I'm sort of okay with.
>
>The fact that everything in containerkit may change name, location, and
>possibly a lot more -- I suspect pete's okay with that and will update
>phoenix/myrmidon/other stuff accordingly when it happens.
>
>Do I miss the point again?
>
>
:-)
Would have liked to have seen more collaboration on the defintion - but
its not problem - excalibur.meta is in place which is critical for any
real container development (actually what I should say is that
seperation of meta data is critical). I'm getting to the point where I
have a reasonbably good idea of the seperation that's needed:
* kernel - the thing runs a container
* container - a thing that manages meta data (kernel specific)
* type loader - a thing that handles internalization of meta info
from XML or serialized form to a meta info implementation
(can be generalized across kernels/containers)
* profile loader - a thing that handles internalization of profiles
(container specific)
So at the end of the day, what's needed is stability on:
(a) a meta-info factory that takes a loader implementation class
and a source (configuration or serialized form) and returns an
object instance that is the meta-info representing the type.
(b) a really stable DTD for the .xinfo document
Both of the above should established be in a seperate package (possibly
as part of framework 4.2). Seperation of the above two would ensure
minimal pain as this area evolves - and there will be pain because
little things (like package names in DTD that reference containerkit)
will propergate across lots of components. Instead - seperate out the
very first interoperability layer (the internalization from XML) - get
in place very good documentation and a test suite and we will have
something tangible to work with.
Pete - do you think that's reasonable?
Steve.
>- Leo
>
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
