Leo Simons wrote:
Hi Steve, Stephen McConnell wrote:Over the past couple of months I've been working on the assembly, meta and Merlin packages as part of the transition out of Excalibur and into the avalon-sandbox project. The transition involved a number of changes that are listed below:
<snip type="description of lots of work I need to think about"/>Next step - cleaning up - polishing documentation - and getting in place a workplan for remaining feature additions and/or structural adjustments.
I think we sorta agreed we needed to be supportive of user (and developer) need, and that the first "next step" the way I see it is to get fortress out of the door. (Besides the ongoing work of getting avalon.apache.org setup, including charter, p&p, etc...
Hi Leo:
I completely agree on the subjects of avalon.apache.org setup, including charter, p&p, etc. On the P&P side I hope to be addessing some points later this evening (Euro zone time). On the subject of getting "fortress out the door", as you know, I have mixed feelings. On one hand I agree that the ECM community are somewhat stranded and this needs to be resolved. On the otherhand I am concerned about the overhead we introduce on ourselves with releases that are (a) probably transient, and (b) limited in community, and secondly, the Fortress release will not actually address the Cocoon community requirements.
I honestly believe that none of the "containment" solutions have sufficient communities behind them at this time and I doubt that this will change significantly until we (the Avalon Community) come up with a common containment architecture. I think that Leo's process of working through context will have a significant impact on this and I also think that the a common solution is quite close.
I'd like to encourage you to use your gained knowledge during development of this new code to help "clean up and polish" the fortress materials. That way, you might be able to help with some "forwards compatibility", as the stuff you're working on in the merlin arena is likely to find it's way into (or be part of) a future version of fortress.
There are two issues we need to deal with here:
1. is Fortress addressing Cocoon requirments
2. structural DNA of containers
On requirements:
The work within the Cocoon community is based ECM and they are
going to be very resistent to and change that existing facilities.
The Cocoon community have been working towards better modularization
of systems through the concept of blocks (packaged functional units
with dependencies and published services). These design goals are
very complementary with the Avalon container architecture
development but are not in any way reflected in the Fortress
code base.
On structural DNA.
There are fundimental low level conceptual differences between
the architecture in Fortress and the achitecture in Merlin that
reflect different user priorities. The Fortress approach is
much closer to the runtime handling of request in an environment
in which almost all objects are pooled. The Merlin architecture
is more macro and concerned with system composition and management.
My objective has been been to establish in Merlin the framework
within which different approaches can be easily plugged-in. A lot
of progress towards this objective has been achieved with the
seperation of the assembly framework from the containment
framework (avalon-andbox/assembly versus avalon-sandbox/merlin).
However, while close, its isn't yet what I think is needed - some
more work is required in Merlin to eliminate exposure of some
some of the internal machinery - but with that in place, I think
we will arrive at a situation where it would be relatively strait
forward to include Fortress runtime handling as an Appliance
implementation (component handler). I see this a "good" and
"practical" solution - but that's somewhat in conflict with the
notion of releasing Fortress because as soon as we hit a release,
restructuring solutions becomes much more difficult.
So at the end of the day I think it comes down to a choice of
either:
(a) release Fortress but accept that convergence will be
difficult if not impossible
or
(b) continue with convergence and aim for a release in
3 or 4 months time
My preference is the second option - but I'm not about to block
the first option (even though I don't think its the right thing
to do at this time).
All of the above leads me to the conclusion that we *really* should be continuing the Fortress/Merlin convergence actions. This can be addressed by the following:
(a) seperate Fortress runtime component handling from containment
logic
(b) package the runtime component handling as an Appliance
implementation (refer avalon-sandbox/assembly)
This enables a independent development of containment strategies and cooexistance of different deployment models. But to achieve this - we really need to stay outside of a release cycle for a few months.
Cheers, Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
