Vadim Gritsenko wrote:

> >So the remaining question is, is fortress/merlin stable and usable?
> >If these both points can be answered positiv, I would say: +1.
> >
> 
> -1 for 2.1. If you read this thread, you will see that the changes are
> too drastic to make this in 2.1, and it already has loads of changes by
> itself. This asks for at least 2.5, or even 3.0.

-1 for 2.1, no question about it.

It is true that Cocoon needs a much better component containment
technology for us to be able to implement cocoon blocks as designed so
far.

But you have my word that I'll continue to -1 any change to the 2.x
family of Cocoon releases if some fundamental contract like marking
interface to represent component behavior stop working.

My suggestion to the current avalon developers that share Cocoon's
concerns (not all of them do) is: think incrementally, think about
migrations paths, think about small evolutionary steps.

I know (by experience) that this is extremely hard to do (or take a huge
amount of time and energy) but Cocoon *is* a stable technology and we
want to continue it to be.

We will not change some fundamental interfaces or contracts any time
soon.

Let me repeat this for those worried guys that are reading this thread:

 WE WILL NOT CHANGE FUNDAMENTAL CONTRACTS UNDER YOUR FEET

Got it? Should I repeat it again? no? great.

If a new component container doesn't allow my home-made avalon
components to run as they did before, this new component container will
not make it into Cocoon, unless an *easy* *well-documented* *simple* and
*effective* migration solution is offered to the user (and to our cocoon
developers as well).

Sure, 15:1 performance ratio is killer, but how much of that performance
improvement goes into our perceived performance when all our pipeline
components are pooled and 80% of our average pipeline time is spent into
xslt processing?

Please, don't take me wrong: I'm the biggest fan of clean and well
designed frameworks (after all, I'm the one who started Avalon,
remember?), but as Avalon 4 took 4 years to become a reality, I'm all
for waiting maybe even *years* before switching to anything new on this
side.

Yeah, I know that a new CM is not Avalon 5, but I'm fear the fact that
with metacoding (that is: xdoclet-like behavioral metadata), the
separation between the two becomes accademic (and it is, in fact,
happening).

So, Avalon 4 states clearly that component behavior is based on marking
interfaces.

Avalon 5 wants to deprecate these in favor of external metadata for a
number of (admittedly good) reasons.

The modern Avalon containers (fortress/merlin/phoenix) deprecate marking
interfaces to define behavior.

Hmmm, tell me: which version of Avalon are you guys implementing? Where
is the line that separates "framework" from "implementations"?

So, the real question should be:

 when should Cocoon use a component container based on the design
principles of the next version of Avalon?

Answer this.

-- 
Stefano Mazzocchi                               <[EMAIL PROTECTED]>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to