cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Netscape and document cache
Date Fri, 17 Nov 2000 09:22:52 GMT


Robin Green wrote:

> Uli Mayring <ulim@denic.de> wrote:
> 
>> On Thu, 16 Nov 2000, Robin Green wrote:
>> 
>>  > (2) It would avoid a lot of XSP junk being stored in the Cocoon 
>> cache which
>>  > doesn't need to be there because it is never used. I know 
>> personally, that
>>  > some sites use XSP for almost everything, and a lot of that is not 
>> very
>>  > worth caching, which means a big waste because it is cached anyway! 
>> Since
>>  > some people have reported OutOfMemoryErrors this could be important.
>> 
>> Can you give an example of this junk that doesn't need to be cached?
> 
> 
> The output of every single Cocoon request is cached, even if there's no 
> point, because Cocoon has no interface for defining if it's sensible to 
> cache something.
> 
> I'm not talking about compiling or "caching" loaded classes, which is 
> different.
> 
>> 
>>  > >I mean,
>>  > >this would break each and every XSP page in existence.
>>  >
>>  > No it wouldn't. I am proposing caching no dynamic content by 
>> default. The
>>  > pages that aren't designed to be cached, would still work. The 
>> pages that
>>  > are intended to be cached, would still work, but slower because 
>> they would
>>  > not be cached - until the developers realised and explicitly 
>> enabled it
>>  > again. It wouldn't break anything in terms of functionality, apart 
>> from
>>  > caching.
>> 
>> My users would consider the pages to be broken, considering how long they
>> take to compile.
> 
> 
> No no, they would still only compile once! The XSP processor does its 
> own thing (it's really a producer in disguise) and this would not effect 
> that.
> 
>> There's lots of dynamic stuff in there, but once it's
>> compiled the code just executes every time a page is called.
> 
> 
> Executes every time? Then your pages will be totally unaffected. They 
> already execute every time. I'm talking about people who declare 
> hasChanged() return false. In that case the output page is served direct 
> from Cocoon cache. They will just have to declare isCacheable return 
> true for it to still serve from cache. I don't think that's much to 
> worry about.
> 
> It should really be an IsCacheable interface, because it's not supposed 
> to vary, but XSP pages can't yet implement interfaces.
> 

This is exactly what was discussed recently on cocoon-dev in the TODO 
list for C2 and Stephano's "[RT] Cocoon in cacheland" 2 or 3 weeks ago.
So +1 for the "Cacheable" interface.

For XSPs, we could add a new xsp:cacheable boolean attribute to the 
xsp:page element that whould generate an implementation of the Cacheable 
interface. This attribute is not java-specific and could also be used in 
other XSP implementations (AxKit).

>>  > Hey this is nothing to do with twisted workflows!
>> 
>> I took your above statement "people use XSP for everything" as meaning
>> that there is some poor coding out there. Why change a default to
>> accomodate poor coding and make it hard for well-designed pages?
>

> 
> Well if all your pages execute every time maybe you are the one having 
> poor coding? ;) ;) Only kidding. Mine are like that too.
> 

-Sylvain


Mime
View raw message