Re: [MERLIN] status report

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