> Now, if the <map:generate src="somecacheablestuff"/> is cacheable, and you > make a change to the transformer "some.xsl", this does not make cocoon > invalidate everything. The part "getCVS" is still valid cached stuff.
Hah, you know, I didn't even think of doing it that way. I'll try calling an internal pipeline on monday and see what I get. I was using the <call resource="..."/> tag and, since the entire pipeline is cacheable, my "longest cache key" was the entire pipeline - meaning that the resource got called each and every time. I finally got point caching to work by putting a pipeline-hint="caching-point=true" attribute on the end of my resource and then turning off smart caching and autocaching in the point caching pipeline, but again the solution seems a bit messy. An internal pipeline (so long as it gets cached) should work much better. > I don't know if this is your problem or I misunderstood the problem. I don't > know how cocoon is going to operate against the CVS server, but if it is over > http, then I think the real hard part of your problem is how to establish > wether a cvs source is valid/should be invalidated or not. I've got custom generators and transformers to handle communications with the CVS server (using Netbean's libcvs), so that won't be a problem. I've figured out a caching scheme that works for me and key generation is working how I want it. Luckily we're mostly getting metadata (rlog, rdiff) about things that shouldn't be changing, so it's pretty easy to cache it. Thanks! Matt --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
