Paul Hammant wrote:
Stephen,
Hi Paul:
I'll try to recap things (and I'm also posting this to the general list because it is relevant to discussions concerning containers and general lifecycle management).
Thanks for that lengthy roll-up. Very valuable for newbies (to an issue) like me.
I've read it and the following discussion between you and PeterD. Peter Royal's flash of inspiration looks interesting.
Yep - I have to dig some more into X-Path to fully get the implications.
Even if it is not a 'third way' for this problem, then it will be useful for other things (at least for me). So I am a little clearer on terminology and the issues generated. Only a little though ;-).
Terms ====
Stephen's words (generalized ?) :
Where composer == Merline/Phoenix/... Container == any composite component (e.g. an ORB) Component == the thing declaring the dependecy constraints
Peter Donald's (specialized ?):
Component A = thing declaring dependencies Component B = a composite component that A depends upon Constraint x, y, z = Constraints that A requires from B Kernel = Merlin/Phoenix
I'm inclined to agree with Peter, however I think this is better :
Component = thing declaring dependencies and that may be depended upon.
Constraint = specialized information for a component's dependancies
I would rephrase this to say that a constraint is structure used to qualify a depedency
Kernel = Merlin/Phoenix/other that handles lifecycle management of components. May have multiple impls.
I prefer composer - because in my mind there is typically one kernel - in the case of Phoenix this makes sence. In the case of Merlin it does not make sence. However, I agree that the term kernal is appropriate when we are talking about the thing executes the assembly and deployment process. From this perspective, when you run Merlin from the commmand line its executing in the role of a kernel. If you use Melin as a component (e.g. via a dependency), then Merlin is more correctly described as a composer.
Container = thing hosting specialized components, using a kernel that may also be a composite component.
I should not have used the word "container" - I think I was up too long :-)
Hmmm, maybe that is not so useful for this discussion. Maybe it is unnecessary term defining on my part.
Its relavant - because we imply lots of stuff in the word we use :-)
Roll-up =======
Could we have another. The discussion have moved on since the last. Maybe it is not so important to re-establish context again. Ideally something along the lines are
Brief descr of goals / issue.
Peter's current proposition with snippets of example code/xml Stephen's doubts with that
Stephen's current proposition with snippets of example code/xml Peter's doubts with that.
It will help my example-orientated (oriented ?) mind to understand what you guys are discusing. It might be that my input is not needed as you are charging off in healthy discussions quite well. Having said that, there are two kernel/comtainers that I am involved with that might benefit (Jesktop and EOB).
- Paul
Hold this throught until after I've checked out the ContainerKit meta-data stuff :-)
Cheers, Steve.
--
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]>
