Stefano Mazzocchi <[EMAIL PROTECTED]> writes: > 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.
The data wrappers can be pretty thin if you've got good naming conventions and data organizations. It's a bit of a pain because you end up having many levels of caching (eg. stuff common across organization, stuff common across departments, cachable for individuals, not cacheable, etc) and you then need to aggregate all these things. Your generators end up being organized by cache availability levels and not by any normal business logic, rather counter intuitive. There's probably a generic type solution for file based repositories where the wrapper would just pick up the directory name and/or file name then a matching generator could use these classes to automatically wrap everything. Not sure how you'd get generic behavior on the invalidation side however; obviously picking up the key is the same, but now you're looking at an action handler or flow class figuring out that cache invalidation needs to be done and knowing that in a generic sense... > > >> 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. As long as it's a light weight repository that would be ok; in our case everything is already fed from a relational database and EJB's... Basically I'd want to be able to populate the repository on a "on demand" basis, though prepopulating for known hot spots would also be good. > Note: push/pull parsing and normalized repository for content storage > are *orthogonal* issues, independend and separate concerns. Hmm, perhaps? Certainly they both can address similar performance concerns. The reason I'd relate them is because I'm still wondering if it doesn't make sense to feed the parser directly from the cache, (the cache then being a collection of PSVI type objects). That's certainly a different direction from JSR 170 and would tie Cocoon very tightly to Cocoon a specific parser (though the whole thing could still be generically useful). Probably still too radical so I'll keep quite on it. > > 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!) Really I suspect that we don't even need Xquery: if an XSLT document request can hit an in memory repository with good performance then 99.99% of our needs will be met... > > 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. I'll probably have to be pretty quite on the whole discussion, not a lot of time for much else (as usual, sigh)...
