Leo Simons wrote:
>>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 =)
>
>
Agreed.
>
>
>>- 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.
>
internal-isation (not i18n)
(ok bad choice of a word on my part)
* type loader - the thing that handles the translation of an external
type defintion (XML, serialized form, etc) to a Meta Info implementation.
* profile loader - the thing that handles the translation of an external
profile defintion (XML, serialized form, etc) to a Meta Data implementation.
Cheers, Steve.
>
>
>
>>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]>
>
>
>
--
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]>
