Geoff Howard <[EMAIL PROTECTED]> writes:
> > Umm why? You can still invalidate the validity in any
> manner you see
> > appropriate, or for that matter, you can still manage the cache of
> > actual data in any way you see fit...
>
> I may have been jumping to conclusions, but my assumption
>
Geoff Howard wrote:
This is definitely an interesting idea, but I can't believe that this
sort of backwards-incompatibility would fly. One option would be to
put a null validity implementation in the Abstract* so subclasses
don't have to do anything, but I can't see that happening in a 2.1
br
Hunsberger, Peter wrote:
Geoff Howard <[EMAIL PROTECTED]> writes:
Again, no change to the impact on the cache. Just less Cocoon code:
everything is considered for caching, no key or no validity, no caching.
Same as today; but currently it's possible not to be even asked for a
key or validity. Goi
Miles Elam <[EMAIL PROTECTED]> asks:
> Okay, here's a wonky thought: why not make all components cacheable?
> So am I off my rocker for proposing this?
No, I don't think so. I've basically suggested that in the long term
this would make sense, I hadn't thought of doing it with the current
C
Geoff Howard <[EMAIL PROTECTED]> writes:
> > >> If the Abstracts (AbstractGenerator, AbstractTransformer, etc.)
> > were >> updated to reflect this, most folks using Cocoon
> would only
> > have to do a >> recompile. Folks who implemented the interfaces
> > directly (Generator, >> Transfor
Miles Elam wrote:
Gianugo Rabellino wrote:
> Miles Elam wrote:
>
>> If the Abstracts (AbstractGenerator, AbstractTransformer, etc.) were
>> updated to reflect this, most folks using Cocoon would only have to
do a
>> recompile. Folks who implemented the interfaces directly (Generator,
>> Tra
Gianugo Rabellino wrote:
Geoff Howard wrote:
2. There is no transformer yet (even if, agreed, it would be pretty
easy to build one);
True, but that seemed quite a bit less work than the solutions you
have been looking at. (though I was only following the discussion
casually)
Not really, since
Gianugo Rabellino wrote:
> Miles Elam wrote:
>
>> If the Abstracts (AbstractGenerator, AbstractTransformer, etc.) were
>> updated to reflect this, most folks using Cocoon would only have to
do a
>> recompile. Folks who implemented the interfaces directly (Generator,
>> Transformer, etc.) would ha
Geoff Howard wrote:
2. There is no transformer yet (even if, agreed, it would be pretty
easy to build one);
True, but that seemed quite a bit less work than the solutions you have
been looking at. (though I was only following the discussion casually)
Not really, since it would be transparent t
Miles Elam wrote:
If the Abstracts (AbstractGenerator, AbstractTransformer, etc.) were
updated to reflect this, most folks using Cocoon would only have to do a
recompile. Folks who implemented the interfaces directly (Generator,
Transformer, etc.) would have more to do, but a cut and paste fro
Okay, here's a wonky thought: why not make all components cacheable?
...well ...sort of...
What percentage of content is cacheable right now? Perhaps a better
question would be what percentage would everyone like to be cacheable
right now? In a perfect world, almost everything would be cache
Gianugo,
Sorry for the long delay. Mini-vacation and only had this email at home
(pop3 here set to remove from server...)
Gianugo Rabellino wrote:
Geoff Howard wrote:
I apologize if I've already mentioned this, but I think there are some
different angles on solving your problem which you may wa
Geoff Howard wrote:
I apologize if I've already mentioned this, but I think there are some
different angles on solving your problem which you may want to consider.
One is implemented in part in the event-cache block but it could be
generalized to work for any component. Unico Hommes wrote a Ge
I apologize if I've already mentioned this, but I think there are some
different angles on solving your problem which you may want to consider.
One is implemented in part in the event-cache block but it could be
generalized to work for any component. Unico Hommes wrote a Generator
(in that blo
Sorry for the late reply. Vacation time + lousy GPRS + heavy spam/worm
activities nearly killed my ability to read email.
Miles Elam wrote:
I'm running into a snag and was wondering if anyone had some wisdom to
grant to me. The current behavior of caching pipelines is to aggregate
the keys of
Miles Elam wrote:
Are you certain this works with _uncacheable_ pipelines? The pipeline
implementation I think only caches a pipeline up to the last cacheable
component whether you have set this expires attribute or not. That is
there I think just for http header in the response for proxy
fr
Gianugo Rabellino wrote:
Miles Elam wrote:
It would be possible to add in some code that if the resource has no
validity objects and the pipeline has an expiry, it creates a dummy
validity object that, if asked, always returns "invalid" but has the
expires timestamp set to maintain the entry.
17 matches
Mail list logo
