avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: Service or not?
Date Sun, 07 Jul 2002 16:40:37 GMT


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:avalon-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message