On 16 Dec 2003, at 11:09, Hunsberger, Peter wrote:
Stefano Mazzocchi <[EMAIL PROTECTED]> writes:
Now, the problem is: if I am not the one who generates the validity (in linotype, it's the directory generator), how can I invalidate it? how can I have access to it?
We use data classes that generate the keys for the generators and whoever else needs them. Each data class used by a generator has a way of getting a key string that is unique to the business logic requirements of that type of data. If you're updating the data you can call that method to find out what needs to be invalidated.
Yeah, but this means that you are in control of the caching logic.... and I'm not if I use "off the shelf" cocoon sitemap components.
The solution to this problem in the past has been "write your own component".... or "extend cocoon components".
Don't know about you, but I'm getting more and more accostumed to the "screw the compiler, use scripting" attitude, blame my utter lazyness or blame a classloader that doesn't load a class directly from source passing it thru the eclipse compiler (which would be totally cool for development, BTW)
The above means that "write your component" triggers some "gosh, can't I do that without code?" kinda attitude that cocoon spoils you so much with.
I'm starting to think that the cocoon cache needs a serious redesign to deal with these issues... and this scares me :-( but it's *waay* too important to let go.
Thoughts?
You may recall I've been pushing for this for a year or so now... Our
needs are perhaps a little orthogonal to the average Cocoon user (or
just extreme), but this gets back to the discussion on push-pull parsers
and having a single normalized repository for all cache items.
What you were talking about is a content repository. JSR 170 expresses *exactly* what you need and implements observation.
Note: push/pull parsing and normalized repository for content storage are *orthogonal* issues, independend and separate concerns.
Please, keep them so: I see no value in restructuring the entire cocoon application using pull parsing.... what you need is XQuery support on top of the repository, then everything can happen in push as we always did (and we are addressing this with JSR 170!)
Lots of discussion on this in the past; no forward movement here (I'm finally getting to bringing 2.1.3 up) but I may have some time to try and discuss more.
I think caching, observable repositories and pull parsing are orthogonal issues, so let's keep them separate and focus on caching at the moment.
-- Stefano.
