cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: strange resons not going beta (was Re: C2: trouble getting streaming to work as expected)
Date Fri, 30 Mar 2001 10:39:53 GMT
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.
> 

Or even configuring a "Expires:" Header, so that the client caches it. 
But this would defeat part of the dynamic nature of some menus like these.

BTW, is there any simple way that cocoon controls "If-modified-since:" 
headers before the cache is in place? I imagine that part of the caching 
subsystem will/could take care of these shortcuts, not even delivering 
content.

Again, I'm not protesting (neither I have any authority for doing it :).
Just pointing that cache is required for a "final" c2 that is usable. 
That it happens under 2.0 or 2.1, or even that you release (as Donald 
suggested) nightly c2aX builds, instead of fully freezing APIs, that's 
your decision.

On the other side, I agree that C2 needs more visibility, and it needs 
it sooner than after. Freezing 2.0 APIs, and then, it caching needs API 
changes, releasing it as 2.1 could be a solution.


> 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



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


Mime
View raw message