cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tagunov Anthony" <atagu...@nnt.ru>
Subject RE: [C2]: Proposal for caching [OT]
Date Thu, 25 Jan 2001 13:28:25 GMT
Me too :))

>Me too... Sorry for not sending more feedback. I agree with Torsten that some of us don't
have
>enough background/insight to jump into the discussion. Please keep up the good work.
>
>-- dims
>
>--- Torsten Curdt <tcurdt@dff.st> wrote:
>> > Hi all,
>> > 
>> > is noone else except Sergio and me interested in having a 
>> > caching mechanism? 
>> 
>> No, me too, me too!!
>> Unfortunately I don't have enough insight for useful comments.
>> I guess this applies to some other lurkers as well ;)
>> 
>> Keep it up :)
>> --
>> Torsten
>> 
I'm DREAMING OF HAVING A GOOD Caching mechanism at Cocoon 2 (I've wasted WEEKS !!! combating
Cache
in Cocoon 1). Sorry that all I can do now is say that I sure want some caching mechanism for

-- itermediate results (year, it's a funny question of to figure out if it's stale..) surely
it should be a configurable
   mechanism)
-- the resources and results we embed via content aggregation. (Should be closely connected
with cocoon:// uri's that are
under work at content aggreagation direction). BTW wouldn't be nice to have such uri's all
round for stylesheets f.e. ?

Use case: we do retrival from the database (vie esql.xsl)
and we use our own hand-made facilities.

We have content aggregation for C1
<incl xecute:href="relative-uri.xml">
  <params../>]
</incl>

-- an expiry period may be set for each request of this kind. (this is an example of caching
policy -- expiry period)

We also do xinclude-s from some URL-s (http://..) so we have made our own version of XInclude
processors
that
 a) has a caching ability
 b) has it's own quite tricky caching policy: we may specify a "manner" of checking hard or
soft and
     a  "check-period".

     "Hard" manner means that as soon as we try to retrive value from cache and it is OLDER
then the timeout, then the 
      cached document is unconditionally invalidated and regenerated

     "Soft" manner means that as soon as we try to retrive value from cache and it is OLDER
thatn the timeout, then we
      get the "timestamp" of the resource and invalidate or not invalidate the cached value
depending on this.

      So, if the mode is "hard" and "timeout" is 0 -- do not cache at all.
            if the mode is "soft" and "timeout" is 0 -- check "timestamp" every time.

      The reason we did so was that checking for the "timestamp" of an URL takes approx the
same time as retriving it as a whole!
      (The web server we address takes much time to start giving ANY data, and quickly gives
it all)

Sorry, this quite out of topic..

Best regards, Tagunov Anthony, C1 developer



Mime
View raw message