Berin Loritsch wrote:
From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
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
implement.
I understand what your saying and its been a little difficult trying to
track what has been going on. Some of the information has been forwarded
to the Avalon list but there is a lot more information over on the Cocoon
Wiki:
http://wiki.cocoondev.org/Wiki.jsp?page=Blocks
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksUseCases
The first link provides references to some of the email threads on this
subject. The second link goes into detail of the concept of block as
managable service unit, and the last link presents some use cases.
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.
Agreed.
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.
I agree that its difficult - but I also think they done a good job in
detailing requirements already and getting this into a form that is
readily understandable and something that can be used as a reference
point. I should also not that the sort of things they are taking about
overlap by about 70-80% with requirements that I'm dealing with.
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.
Yep - I agree completely.
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.
Short answer - Yes.
Classes are now much smaller and things are much more manageable.
The restructuring process was largely trigger by your comments. The
main issues you raised concered the classloader implementation which
incorporated the type, service, profile and assembly management code.
That has massively improved - type, profile and service have been
seperated out into seperate repositories, assembly functions are not a
seperate pluggable service. Code size has reduced to about half. But
documentation needs to updated (i.e. I'm confident that there are doc
inconsistencies).
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.
I did (do?).
One of the things I've been having a little trouble with is
identifying where seperation of the container verus handlers
should be drawn. Something really helpful would be a test case
that demonstrated Fortress component handling independently of a
container. That would help me figure out the intersection points
with the code in the assembly package.
or
(b) continue with convergence and aim for a release in
3 or 4 months time
That is a long time.
I know - and to be frank I'm also taking into account here time for
mutual understanding. I.e. I'm taking into account time for refactoring
at the Fortress level and assembly level.
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.
LOL - its not that bad!
The more we discuss what the objectives/issues/targets are, the more
comfortable I'll get. That's important because you are not guaranteed
to be around to take care of issues (I'm talking about your time
constraints here) and I'm looking into the future and imagining how
capable we (the rest of us) will be in supporting this. Maybe I'm
just too conservative!
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
pike.
- Provide docs that say how to prepare the code for the future.
OK.
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.
That would be terrific - although I think would result in work on the
systems below Merlin - i.e. assembly and meta areas. It is also
consitent with the feedback I'm getting (people out there want to
see convergence).
3) Release Merlin in 3-4 months time as the next generation container.
Timeframe is feasible.
This approach solves the issues of #1 giving our users something
better now,
+1
#2 unifying our development efforts and strengthening
our community, and
+1
#3 a planned upgrade path.
+1
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.
Could you put up a release plan (action list) on the Wiki and I'll
jump in and help where I can.
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]>
