C2 Scalability Issues

[Stefano Mazzocchi <st...@apache.org>]

Berin Loritsch wrote:

> The approach I would like to take for the Cocoon component model is
> a refining of all the interfaces.  Unfortunately, that would require
> some backwards incompatible changes. :(
> 
> When I get the ContainerManager done and a new scratchpad
> implementation of Cocoon (as extending AbstractContainer), Main, and
> CocoonServlet; we can start to assess the real limitations that the
> current component model has with scalibility.
> 
> Until then, you are going to do alot of work for only marginal gains.

Ok, small scalability is a serious problem and I think that we can
decide to break back compatibility (with the 2.1 series) if this proves
to be architecturally valuable.

So, please, let's list the changes that you think would be sufficient to
solve the scalability problems you perceive.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


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

Re: C2 Scalability Issues

[Berin Loritsch <bl...@apache.org>]

Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
> 
> 
>>The approach I would like to take for the Cocoon component model is
>>a refining of all the interfaces.  Unfortunately, that would require
>>some backwards incompatible changes. :(
>>
>>When I get the ContainerManager done and a new scratchpad
>>implementation of Cocoon (as extending AbstractContainer), Main, and
>>CocoonServlet; we can start to assess the real limitations that the
>>current component model has with scalibility.
>>
>>Until then, you are going to do alot of work for only marginal gains.
>>
> 
> Ok, small scalability is a serious problem and I think that we can
> decide to break back compatibility (with the 2.1 series) if this proves
> to be architecturally valuable.
> 
> So, please, let's list the changes that you think would be sufficient to
> solve the scalability problems you perceive.


First things first....  Let me provide a way to divorce ourselves from
ECM which I think we have proven is waaayy to ineficient for our needs.
After we have a clear migration path for the Container hierarchy
(i.e. root Cocoon container, and every sitemap/subsitemap as a container).

We can get to this point without breaking backwards compatibility.  At
that point we can have an objective platform to start tuning the 
component model.  Our aims need to be memory efficiency, and efficiency
of the critical path.

<hint>
   The more people I have looking at the ContainerManager code and
    ironing out bugs, the quicker it can get done.  Right now, I have
    to steal an hour here and there which isn't conducive to real
    development....
</hint>

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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