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 09:30:49 GMT

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?


>- 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

digital products for a global economy

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

View raw message