Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Fri, 30 Mar 2001 11:28:23 +0100
Content-Type: text/plain;
	format=flowed;
	charset=us-ascii
From: Stuart Roebuck <stuart.roebuck@adolos.co.uk>
To: cocoon-dev@xml.apache.org
Mime-Version: 1.0 (Apple Message framework v387)
In-Reply-To: <3AC4182A.952D9E36@apache.org>
Subject: Re: strange resons not going beta (was Re: C2: trouble getting
  streaming  to work as expected)
Content-Transfer-Encoding: 7bit
Message-Id: <E14iw8m-000Kn8-0A@finch-post-10.mail.demon.net>

A lot of the work we are doing couldn't go prime-time on live C2 without a 
cache (we currently output content from C2 and serve it statically).  That'
s not specifically the fault of Cocoon but inherent in the nature of some 
of our generators and the level of multiple pass XSLT processing we do.  
We could work round it by building our own cache and moving our XSLT code 
more from code maintainability towards code efficiency, but a C2 cache 
would make that work redundant, so we're not too keen.

I'm not really pushing things either way, but I thought it was worth 
indicating that there are folk out there who would put C2 caching up there 
as a critical feature.

Stuart.

On Friday, March 30, 2001, at 06:22  am, Giacomo Pati wrote:

> Santiago Gala wrote:
>>
>> Berin Loritsch wrote:
>>
>>> Giacomo Pati wrote:
>>>
>>>> Quoting Berin Loritsch <bloritsch@apache.org>:
>>>>
>>>>> No that isn't.  Cocoon 2 is still (for some strange reason) 
>>>>> considered
>>>>> Alpha software, so there are no direct downloads.
>>>>
>>>> This is the first time I've read that the missing features 
>>>> (aggregation and
>>>> caching) are strange reasons not going beta/production with Cocoon 2. 
>>>> Let me
>>>> check this out. Who else finds this is strange.
>>>>
>>>> 1. Can you imagine that C1 users today will switch to C2 without a 
>>>> cache?
>>>>
>>>>    The fact is that C2 cannot compete with C1 (with cache enabled)
>>>>    for static content delivery. This might lead to the situation
>>>>    that we will support and maintain two versions at the same time.
>>>>    C1 for faster static content delivery and C2 for dynamic 
>>>> publishing.
>>>
>>>
>>> Regarding Cache on C2.  Cocoon 2 is fast enough on my test systems and
>>> scalable enough on my systems that cache isn't critical.  We are talking
>>> blazing.  Cocoon 1 needs cache to even be useful--this is simple a state
>>> of DOM vs. SAX architectures and the speed of the libraries we are 
>>> using.
>>> Cocoon 1 has discrete produce/process/format stages, while Cocoon 2 (due
>>> to the event based SAX model) does generate/transform/serialize in each
>>> event.  The stages are performed in effect simultaneously.
>>>
>>
>> I agree, except for some SVG examples, for instance the svg-welcome. A
>> cache would be great to have some kinds of processing, like svg or pdf.
>>
>> I would sell very well an automated generation of graphic navigation
>> bars, for instance, but that calls for a cache, obviously.
>
> For these types of caching you best put C2 behinde a proxy server.
>
> Giacomo
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>> For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


-------------------------------------------------------------------------
Stuart Roebuck                                  stuart.roebuck@adolos.com
Lead Developer                               Java, XML, MacOS X, XP, etc.
ADOLOS                                             http://www.adolos.com/

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