cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Accessing cache validities from flow
Date Wed, 17 Dec 2003 22:42:24 GMT

On 16 Dec 2003, at 11:09, Hunsberger, Peter wrote:

> Stefano Mazzocchi <> 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 

>> 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.


View raw message