Joerg Heinicke wrote:
On 25.10.2005 09:06, Bart Molenkamp wrote:
(Can it be discussed here, or do I need to add them as comments to
the issue too?)
Of course.
I don't totally agree with your latest comment. The CacheValidity
won't solve the problem, IMO it's a problem with the ID being generated
that is not unique.
Yes, the non-unique ID is a problem as you can see with the issues
described by Sarah. For her repeated calls to the same URI brought
always the same fragment. Generating unique URIs solved the problem
for her - but also switches off any caching.
In my case, the URI for a report is always the same,
but the contents of that report is based on who is calling it. Multiple
users can call the same URI, each resulting in different content.
Breaking caching by generating unique ids doesn't seem like much of a
solution. I have pipelines that operate in the same manner that you are
describing. The src parameter is the same for every client. I solved
it by implementing my own source resolver. It adds something unique
about the client to the url that is returned on the get URI call
causing each client to have their own copy cached.
Ralph
