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 Mon, 08 Jul 2002 02:24:08 GMT

Peter Donald wrote:

>On Sun, 7 Jul 2002 19:30, Stephen McConnell wrote:
>>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?
>I dont see any advantage for me in doing it that. Theres no chance of you ever 
>doing some of the things you want to do in anything I am involved with. You 
>dont seem to want to do it the way I have suggested, 

Suggested or mandated?  

I would like to see the development of a common meta framework - 
preferably on a step by step basis.  It is clear that the current 
containerkit package goes unnecessary boyond what is needed - and due to 
resitence to discussion of change to accomadate any other requirements 
other than your own - the potential for application beyond the static 
notions implicit in Phoeinx are significantly constrained.  However, if 
you decompose the package you come up with a set of layered services. 
 Each layer represents a different degrees of lock-in.  For example, a 
common DTD is a privative level of interoperability without which Avalon 
relected container approaches will fragment.  If we were to go beyond 
the common DTD, we have have resources supporting XML defintion loading 
which can be independent of a particulat meta-info model implementation. 
 Beyond info model loading we have a potential for a comon info model - 
and in contrast to your conclusion - the info medels between 
containerkit and merlin are equivalent.  While I don't like the 
existance to two models, I'm not will to accept force-fedding of 
solutions.  Perhaps a reality check in is order - the tangible 
difference at the info models is that the meta.info package uses a more 
consistent and more easily understood API.  It would be a trivial 
exercies to establish agreement on a common API.

>hence you will only end 
>up whining again. I think the best idea would be for you to do with merlin 
>whatever you want and be done with it.
>The metainfo layer is already incompatible and this incompatability is only 
>going to incerase in the future. Given your designs I suspect that merlin 
>enhanced metainfo files will not load in any other containers anyhow.

Perhaps you have not been tracking the work I have been doing on Merlin 
development? If you take the time and effort, you see that it is 100% 
compatible with compoents declared in containerkit.  While its ammusing 
to listen to your assertions of gross differences - the reality is that 
the two models are functionally equivalent.  Perhaps you should take a 
look!  If you not sure about the compatability issue - try installing a 
containerkit component in the new Merlin packages and you will see it 
working, assembly, handling dynamic assignment of dependecies across 
container (the sort of thing that's kind of difficult to achieve in 
static containers).  You could also try running one of the several 
example component from the new merlin package under containerkit - but 
I'll save you the trouble - it works.  And the reason why is that both 
models share a common DTD (see a pattern here?).

>So what possible reason could I have to work with you? Merlin does not have 
>any components I need or want and unlikely to have any in the future. I am 
>done arguing and thus it is less work to route around you than to try and 
>work with you. I have achieved a model that will enable compatability of 
>components between Myrmidon, Cocoon and Phoenix which is what I set out to 
>achieve. The only draw card was that I would not have to write the stuff that 
>is likely to be in Merlin. However thats not likely to occur, so I will have 
>to rewrite it all anyway.
>If you want to use what I write, feel free to. If you want to extend the stuff 
>in ways that I suggested then I will help you. If you want to do your own 
>stuff then feel free. I wont let you push it into framework as it is not 
>going to be what Phoenix, Myrmidon (or Cocoon hopefully) uses.

Do correct me if I wrong - but what I proposed is exactly those pieces 
that are common - a.k.a the same.  This is not about dragging you in a 
direction - it is about moving forward in achiving concensus at the very 
lowest possible levels on how containers can work in a component 
interoperable fashion.  That seems to me to be the priority.



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