> From: Paul Hammant [mailto:[EMAIL PROTECTED]]
>
> Avalon Committers : I'd like a vote of confidence please.
+100 for trying, mate.
+1 for keeping on trying, but
+0 for your chances of success.
Mediation is only useful if the two sides want to get along. So far
it seems like Peter and Stephen are fine with making any compromise and
that
they are happy to include any Merlin/Phoenix feature - as long as the
end result
is *exactly* like they intended it all along.
The man with the plan, and Heaven help anything that the straight line
from either of them to their goal intersects. I don't mind that - with
an exception I'll get back to below - design by Guru is a remarkably
fast way of getting good stuff done fast fast fast, because you don't
have to spend time explaining the vision or plan and align everyone.
I'm not the slightest surprised at Peter's two-week attribute-driven
blitzkrieg - if anything it is that the business logic wasn't finished
after 2w, but I guess management takes time.
I'm not sure that the Phoenix way is the way to go - too static. I'm not
sure the Merlin way is the way to go - too much magic. All I want
is no changes to Framework. As long as Avalon/Framework has all
contracts
and all classes needed to write a container or a component, I'm fine.
------------
Nicola's proposition of containers within containers seems like a
worthwhile
solution for now - only problem being how you handle lookups:
Container X hosts component A. It also hosts container Y, which hosts
component B:
X -----+----- A
|
+----- Y ----- B
Now when A does lookup(B.ROLE) (to use ECM notation, you know what I
mean),
X must not only check
+ itself (does X contain a B?)
+ it's parent CM (does the parent CM have a B?)
as is done currently in the ECM, but also
+ all its embedded containers (does Y have a B?)
Meaning that Y must somehow expose a Container interface (I guess
similar to the ServiceManager interface).
If we can have this, then
+ Phoenix can evolve in any way Peter sees fit.
+ Merlin can evolve in any way Stephen sees fit.
+ <insert name of next great container> can evolve
in any way <author> sees fit.
I also think this will have the least impact on Merlin/Phoenix.
Phoenix is already embeddable (I think), and Merlin surely is.
And the problem of trying to come up with the one true container pretty
much disappears. Best of all: Avalon/Framework is unchanged.
/LS
(Alternatively we could just dump all this component portability
thing and get on with everything like we did before.)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
