What about using a similar approach to generate the cache? I'll try to set up a test environment and to give it a shot if you have nothing against it!
Do you refer to the fact that it uses list of request parameters and its values as a cache key?
Yes, I'm against it. Request parameter in previous email was simply an example - it could be anything from the environment at large (== JVM where application is running + OS + ...).
Yep... I see your point, you're 100% right...
Proper solution will be composed key similar to the composed validity in IncludeTransformer. This also can be made configurable: in simplier cases, you won't need aggregated key and can use transformer as it is now.
I was thinking about one thing... The one thing that troubles us is the "request". That introduce a degree of variability that (i don't know to what degree), might be counter-productive to analyze and cache...
What about if we were doing "subrequest"s, much like in Apache... I mean, why making the "included" request inherit all the varible stuff? Wouldn't it be simply easier to create a new request/response and start from a clean status.
Then we could re-create the request by something like:
<incl:include src="proto://whatever"> <incl:param name="parameterName">value</incl:param> </incl:include>
Pier
smime.p7s
Description: S/MIME cryptographic signature
