avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Merlin's Future with Avalon
Date Thu, 17 Jul 2003 01:37:10 GMT


Berin Loritsch wrote:

> I hope this is not as ominous as it sounds, but I want to get a feel for
> the community on the whole Fortress/Merlin/Phoenix scenario.  We 
> currently
> have two officially released and supported containers: Fortress and 
> Phoenix.
> Both have enjoyed a variety of eyes on the projects, and increased 
> exposure
> due to their release status.  Now Merlin is nearing the point where it 
> would
> like the same benefits of Fortress and Phoenix.
>
> Before I can be OK with that, we need to ensure that all user components
> are defined consistently across all containers.  The meta API separated
> out is a step in that direction.  We need to be assured that the same
> component used in Merlin will continue to function in Fortress, and vice
> versa. 


Berin:

If I take your "before I can be OK with that" statement literally, I 
should point out to you that there are things in Merlin that are just 
not possible in other containers.  These features (some of which have 
been recently exposed by Vinay in his post concerning custom service 
attributes) are beyond classic Avalon - they go into the area of 
distributed service management.  I am personally really interested in 
this area and I see lots of adventures in this realm - realized and 
delivered through the Merlin platform - as not necessarily compliant nor 
consistent with existing Avalon containers - in fact these very features 
are pushing beyond the "accepted" envelope.

Is that a good thing - YES.

>
> To that end, we need to focus on the AMTAGS proposal and the Context
> clarifications.  Currently, there is a similarity in some of the 
> component
> definitions between Phoenix and Fortress, with Merlin being divergent in
> these areas.


Slow down a moment - your providing some misleading information here.  
The AMTAGS spec as it stands today is simply insufficient with respect 
to both Merlin and Phoenix.  The work going on under the Avalon Meta is 
addressing a complete model - but as you are aware, "AMTAGS" do not 
include a declaration of a version. With consideration of this the 
revision to AMTAGS in the process of development is addresses a complete 
solution.  That revision is not yet complete as work still remains to be 
done with respect to Phoenix requirements. To be very clear - neither 
Phoenix nor Merlin support AMTAGS  because AMTAGS  are woefully 
insufficient to express a complete component contract.

> We cannot have Melin be divergent.  We need one spec to drive the user
> expectations. 


One must be careful in how one positions something as divergent.

Which of the following existing and divergent characteristics within 
Merlin would you like to eliminate?

  1. ability to provide a complete meta-info model
  2. ability to incorporate legacy Avalon component models
  3. ability to incorporate non-Avalon component models
  4. ability to separate deployment versus runtime dependencies
  5. ability to provide meta-data driven context creation
  6. ability to support context casting (e.g. BlockContext)
  7. ability to support alternative contextualization strategies (e.g. 
Servlet.getContext())
  8. ability to support distributed component semantics
  9. ability to auto-assemble and de-assemble components
 

> Beyond that, I have nothing against Merlin.  It solves some user needs,
> otherwise it would not have been written.  I think with more eyes on it,
> the internals will likely be improved without breaking the client's
> code.


I would go further than the assertion that it "solves some users 
needs".  What Merlin is about is pushing the envelope on what 
containment is all about.  It's a complex platform that is very 
adaptive.  Most importantly - it is a platform that is forcing this 
community to address a bunch of issues.  It forcing us to come to terms 
with the notion of "portability", "interoperability" and in due-course 
"distribution".  Merlin is an adventure - even more important - Merlin 
will continue to push the envelope - it will (if I have anything to do 
with it) challenge accepting thinking, go further and more courageously 
than any container has gone before (umm, sounds like Star Trek - but 
that kind of makes sense - its about going way beyond - into things we 
haven't solved).

I think this is a good thing!

So what's your opinion - are you conservative or democrat?

Cheers, Steve.

>
> The all important question is what is the developer interest in this
> container?  Who else is willing to put their eyes on it and time to
> maintain it?
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message