Pier Fumagalli wrote:
On 27 Sep 2004, at 21:06, Vadim Gritsenko wrote:
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>
Well, if the only thing which troubles you is request, then you can easily do this now with simple:
<i:include src="cocoon://pipeline?param=value"/>
And be done with it. You won't need any changes in IncludeTransformer at all.
Even better, I think you can implement a protocol which makes parameters of original request unavailable.
Unfortunately, this does not help with issue I'm having. In my case internal pipeline obtains everything it needs from environment on its own - this allows to create static URLs (like cocoon://user/country) which can be included into the CMSed content and these static URLs will generate appropriate (customized / personalized) content depending on current environment (session / cookies / virtual host / etc).
Same issue, IIUC, will also appear in block scenario, when interface to the skin block is fixed as set of block:skin:// URIs, and skin implementation can return personalized skin based on user preferences or something.
So, how about doing it right the first time? ;-)
Vadim
