Re: [MERLIN] status report

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