cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: Identifier used in FragmentExtractorTransformer
Date Sat, 29 Oct 2005 00:35:09 GMT
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.

How do you differentiate the user? The same way you have to do it for 
the cache key of the original XML, haven't you? This is why I thought it 
is just a matter of caching.

> A cache validity won't solve this, there is just a need to store
> multiple fragments in the same store.

And where is the problem to generate different cache keys per user?

> Besides that I think that caching is done at the pipeline level: if
> the generator, transformers and the serializer indicate that the cache
> is valid, then the cached content will be returned and in that content
> of course the link to the extracted fragment - but the fragment isn't
> extracted again.

FragmentExtractorTransformer and FragmentExtractorGenerator are sitemap 
components, so where is the problem?

> So I think that it is just as simple as to generate an unique ID.
> Maybe some UUID, maybe something with a SecureRandom (like how
> continuation IDs are generated). Also, I suggested to move this ID
> generation to a protected method, so that users can override that method
> in the transformer and implement their own method to generate an ID
> (won't break the current way that the extractor is working).

UUIDs won't solve the problem as they remove any caching as described 
above or in the bug report.

The protected method can solve the problem, but IMO it should be 
possible to solve it once for all use cases, not individually by every user.

Jörg

Mime
View raw message