> Would have liked to have seen more collaboration on the defintion me too. But if there is a business need for this stuff right now, well...I still see quite a bit of improvement over the previous situation so I won't be complaining =)
> - 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) note in phoenix we have * bootstrap - thing that starts/configures the embeddor * embeddor - thing that starts/configures the container * container - thing that runs hosted apps * kernel - the core container engine which sorta works well. it's a little bit like: * BIOS * bootloader * OS * OS kernel > * 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) i18n is just a side-issue, the most important thing is that the meta info is generalized across containers. > 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 it seems to me (a) is more important than (b), you can always do translation of the .xinfo stuff automatically. Just a sidenote. > 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. sounds good. - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
