Re: [wsrp-wsia] [change request #128] cache invalidation due toperform*Interaction()

[Michael Freedman <Michael.Freedman@oracle.com>]

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:

>Document: Spec
>Section: 6.2.1.2
>Page/Line: 39/10
>Requested by: Rich Thompson
>Old text: [insert new paragraph]
>Proposed text: Consumers invoking either performInteraction() or 
>performBlockingInteraction() MUST treat any markup cached for the 
>equivalent MarkupParams (i.e. the MarkupParms structure passed to the 
>invocation updated with any honored newMode or newWindowState requests and 
>any returned navigationalState) as if the expiry time had elapsed unless 
>the response includes a new CacheControl structure indicating the cached 
>markup is still valid.
>
>Reasoning: I had promised last Wednesday to post a proposal for how 
>interaction processing impacts cached markup.
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>  
>