avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject RE: [MERLIN] status report
Date Mon, 06 Jan 2003 14:10:52 GMT
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> 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.

:/ Without those requirements trickling down here, it is difficult
to address them.  They should affect where A5 goes, and the
common container.  Without a list of them it is difficult to

> >
> > 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.

1) Cocoon is not our only customer.
2) Without seeing those requirements trickle to this list, we don't
   know what to implement.  I have had to limit the number of lists
   I subscribe to--and there is even more traffic on the Cocoon list
   than here.  It's hard to follow.

> 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.

The strength that Fortress has is that as the environment changes,
it can adapt more easily at runtime.  It is essential in very
dynamic systems.  It also limits the amount of resources consumed
at any one time because things are resolved on demand.

>   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 you are making your class sizes smaller?  One of the chief
complaints I had about Merlin the last time I looked at it was
that it was very monolithic.  Instead of one class handling every
variation, there were instances where two or three cooperating
classes that were focused would have resulted in easier to understand
code that is more modularized.

>   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

Fortress has the concept of heirarchical containers.  In fact the
concept was more to be container agnostic.  In other words, vastly
different containers could be controlled by the same system.

In practicality, I realize that people are going to relate
the default Fortress container with Fortress.

>   or
>   (b) continue with convergence and aim for a release in
>       3 or 4 months time

That is a long 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).

Ah, the stance of neither hinder nor help--very diplomatic.
I understand your reticense BTW.

> 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.

I see.  But instead of wasting our time on separate projects why not
take this approach:

1) Release Fortress so that ECM users have *something* that is better
   than what they currently have.
   - Provide docs that say something even better is coming down the
   - Provide docs that say how to prepare the code for the future.

2) Focus all our pooled development efforts on making Merlin better.
   - Provide a migration path like descriptor generators and assembly
     converters (XTC project).
   - Have Merlin able to do everything that you can do in Fortress.

3) Release Merlin in 3-4 months time as the next generation container.

This approach solves the issues of #1 giving our users something
better now, #2 unifying our development efforts and strengthening
our community, and #3 a planned upgrade path.

Even though we know they are completely different containers, we
should be able to make it appear to the users that one is a successor
of the other.

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