My preference is that we stick with the decision we made in the November F2F which recognized the complexities of invalidation caching and deferred any specification of such until after 1.0. Our current model is based on a well understood and time tested caching model. Invalidation, though ultimately an important developers tools for achieving optimal performance needs our time and energy to specify a complete and flexible solution. Our current solution is satisfactory. As cache maintanence is controlled by the consumer, consumers are free to provide the semantics you describe in this change control and market themselves as a better solution without our specification saying anything about invalidation. Portlets running on systems without this feature merely receive "stale" data/content -- something that is inherent in caching systems/portals/consumers anyway.

Some reasons for deferring: We should be concerned about implementability by the consumer. Though some consumers will deal with the complexities of implementing invalidation based caching, we shouldn't require all consumers to do so. Such consumers, however, will likely find it easy/convenient to implement our current caching semantics. Ultimately, work should be done to allow consumers to support caching levels. Adding wording/function as you are suggesting to our current specification prevents such behavior.

We should be concerned about extensibility in the future to provide a richer solution. Though, all or nothing invalidation is both convenient for the developer and affords an easy specification, our experience shows that this ultimately must be coupled with a more flexible invalidation model where the portlet can explicitly control each piece of content to be invalidated. Though more work, [invalidation] caching is about optimization and optimization in general involves more work/a deeper knowledge to the true nature of interactions. -Mike-

Rich Thompson wrote: