Hello Matt, I don't really understand your thinking about caching...it is not
like cocoon either caches the lot, or nothing. Then again, you have multiple
options of caching mechanism...though I must admit I am not familiar with
Cache-Points.
I think you are thinking about stuff that cocoon handles pretty well, for
example if we have someting like,
<map:match pattern="getCVS">
<map:generate src="somecacheablestuff"/>
<map:serialize type="xml"/>
</map:match>
<map:match patter="index.html">
<map:generate src="cocoon:/getCVS"/>
<map:transform src="some.xsl" label="xml"/>
<map:serialize type="whatever"/>
</map:match>
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.
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.
AS
>
>
> I'm looking for guidance on the best way to implement caching in the
> following setup. I've got a resource that generates XML data that I
> want to view in multiple formats (simple enough). At the moment, I've
> only got XML, HTML, and text views, making my pipeline something like:
>
> R - S(xml)
> |_ T - S(html)
> |_ T - S(text)
>
> What I want to happen is to have the resource be served from cache
> whenever possible because it's doing expensive operations against a
> CVS server. This seems like something that Cocoon would do very well,
> but I'm not sure of the best way to approach this; several ideas:
>
> Idea #1: Solve the problem using Cocoon Views + Cache-Points, but I
> think that's going to introduce other problems down the line because I
> will eventually be adding other resources that will need their own
> processing to produce HTML, text, etc. views. That will force me to
> have lots of views (e.g. resourcea-html, resourceb-html,
> resourcea-txt, resourceb-txt etc.), all of which could be erroneously
> applied to the wrong pipleline (since the view is supplied as part of
> the query string). Maybe that's not an issue, but it seems messy to
> me. Has anyone else done something similar? How well did it scale?
>
> Idea #2: Is it possible to use the Caching-Point pipleline and
> caching-point pipeline-hints on pipelines that *don't* include views?
> If so, I could make something close to the resource a cache point and
> generate content from there. Also, are there any examples of using the
> caching-point pipeline with pipleline-hints? I haven't been able to
> find much so far.
>
> Idea #3: I know that if I introduce a non-caching component
> immediately after the resource, everything works because the longest
> cacheable piece of the pipeline occurs before the view specific
> processing. But again, this is messy.
>
> Thanks!
> Matt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
