Re: Event Cache block

[Geoff Howard <co...@leverageweb.com>]

Unico,

Thanks for taking a look at this with me, comments inline:

Unico Hommes wrote:
> I've checked out your event-cache code just now and like to make some
> comments.
> 
> One thing I found was that the EventRegistry.init() method breaks IoC in
> Avalon. I think it's better to have initialization be done by the Avalon
> container as part of lifecycle handling. This way Avalon can control
> when the component gets initialized. Since EventRegistry has a
> thread-safe lifestyle the same instance is available to other components
> as well. A property that tells whether or not persistent state was
> successfully regained would allow this.

I agree, and at various stages on my HDD it was that way.  IIRC the 
issue I never solved cleanly was the fact that it needed to tell the 
Cache(Store) if there was a problem retrieving persistent state.  At the 
time though I was not as confident in the lifecycle contract regarding 
dealing with other components in initialize().  But I now think IoC can 
be done more cleanly there pretty easily.

> The other thing I was wondering about is why not use Store component in
> DefaultEventRegistryImpl so that it won't have to handle persistence
> itself?

I thought of that, but thought there could potentially be some circular 
issues there that I didn't have brain cycles to think through carefully. 
    Actually, it could be the opposite: it may get rid of some of the 
issues with failing to retrieve persistent state, since it would either 
all be there together or not.

> I have been thinking about an easy way to add all this functionality to
> the pipeline and figure that a nice way to do it is to have a sort of
> EventCacheGenerator that wraps any sitemap defined generator, delegating
> al the real generating to the wrapped generator but taking care of the
> handing out of Validity objects based on parameters it gets from the
> sitemap:
> 
> <map:match pattern="blah">
>   <map:generate src="event-cache">
>     <map:parameter name="delegate" value="file" />
>     <map:parameter name="event-type" value="name-value" />
>     <map:parameter name="event-name" value="db-table" />
>     <map:parameter name="event-value" value="customers" />
>   </map:generate>
>   <map:serialize />
> </map:match>

> This way we get event-cacheable sitemap components without having to add
> that functionality to each individual sitemap component.

That's an excellent idea.  You can see from the sample extended file 
generator in the block (which serves no purpose ATM) that I was thinking 
it would have to get handled by individually extending each Generator. 
Delegation would be much better.

> This is actually based on a use case that came up yesterday from one of
> our site developers. He uses cinclude transformer for content
> aggregation. Some parts are generated from a backend for which we have
> an event-cache equivalent system in place. The cinclude transformer has
> only a timeout sort of caching mechanism as you may know, but our
> client's case requires real-time updates so we can't use that. Instead
> he needs the content-aggregating pipeline to be invalidated at certain
> backend events as well. In this case probably a declaratively more sound
> approach would be to also have a Transformer wrapper for event-cache. 
> 
> If you want I could code these up and send them to you? What do you
> think?

That'd be great - except it'd be better to send a patch through Bugzilla 
so I'm not the only one who can act, and so it doesn't get lost.  When 
my wife & kids get back this afternoon I may be out of commission for a 
few days!

Geoff