On Thu, Jan 7, 2010 at 2:49 PM, Ezra Parker <[email protected]> wrote: > I completely agree with Dan's take on this (and I must say his > explanation was far more comprehensive and eloquent than mine). The > only stumbling block here is the fact that this approach doesn't work > under the current event caching implementation -- events that are > queued via results will not be cached, only the initial event that is > initiated is cacheable. > > I would suggest that an enhancement which modifies the caching > behavior to add support for caching of queued events is in order -- > I'll go ahead and submit a ticket for this. >
I also agree that caching of queued events would be a useful enhancement. However we should tread carefully here as caching queued events is intrinsically more complicated than caching top-level requests. Caching of top-level requests is straightforward: cache the final view after the event handler queue is complete. This works because there there is no application processing that occurs after a cache hit on a top-level request, and the only output that matters after the event handler queue is complete is the final view. Caching queued events is more complicated: - Events that follow the queued event could use any view queued by the event, not just the last view. - Events that follow the queued event could use values set or modified by the queued event. - The queued event could issue results and queue more events. My biggest concern is that if we release a naïve implementation of queued event caching that does not consider its effect on scenarios like the above then we may get flooded with bug reports and conflicting enhancement requests on how the caching may be "fixed". Note that I refer to top-level *request* caching versus queued *event*caching. I make this distinction because the view that is cached by a top-level event handler is often not defined in the event handler itself, but in the handler of a queued event. However when it comes to queued event caching, we most likely only want to cache views defined as part of the event. This raises the question of whether this should include views defined through an event type: I suspect the answer to this is yes but I'd need to look at that a bit more. So, before caching of queued events is implemented, I would like us to clearly define the following: 1. The semantics of queued event caching, including the relationships and/or distinctions between queued event caching and top-level request caching 2. Any special requirements for a queued event to be cacheable, e.g. no queuing of additional events 3. The behaviour of the framework when a queued event marked as cacheable does not meet the requirements for caching We would of course need good documentation to accompany the implementation to assist developers in navigating the various inevitable "gotchas" of queued event caching. Anyways, please think about how queued event caching ought to behave to cover the many different ways that it may be used *and* abused. Cheers, -- Dennis
-- Model-Glue Sites: Home Page: http://www.model-glue.com Documentation: http://docs.model-glue.com Bug Tracker: http://bugs.model-glue.com Blog: http://www.model-glue.com/blog You received this message because you are subscribed to the Google Groups "model-glue" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en
