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 have more
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
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,
Transformer,
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, Transformer, etc.) would
Miles Elam [EMAIL PROTECTED] asks:
Okay, here's a wonky thought: why not make all components cacheable?
snip/
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
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.
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
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
based on
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
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
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
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
12 matches
Mail list logo
