RE: [wsrp-wsia] [change request #187] Cacheability and perform*Interaction

[Andre Kramer <andre.kramer@eu.citrix.com>]

Obviously, I like Alan's proposal, as a very practical behaviour that we
should at least describe (even if we end up not specifying exact behaviour).
It should, however, state that "the consumer cache may contain more than one
piece of cached content for a portlet and that all of the cached content for
the portlet is to be considered expired on an action". [Otherwise all
portlet navigational state would be required to carry some sort of portlet
state counter or unique identifier.] The consumer can then still try to
refresh one item (for the markup parameters checksum of the action) by
supplying its validation tag.  At least, that is how I read JSR168. JSR
portlets would always re-generate the markup, as the JSR only supports
expires (a pity that there are no validation tags for now). 

How about taking Alan's text as the basis for an appendix (WSRP 1.0 and JSR
168 Caching) and having Rich's alternative text reference the Appendix? We
could give the scheme a new UserScope name "perApplicationUser" (boarder
than JSR168, for all portlets in an application v.s content mode of
operation).

regards,
Andre

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 26 February 2003 21:40
To: wsrp-wsia@lists.oasis-open.org
Subject: [wsrp-wsia] [change request #187] Cacheability and
perform*Interaction


Document: Spec
Section: 6.3.x
Page/Line: 39/9
Requested by: Alan Kropp
Old text: [none]
Proposed text: [new section: 6.3.4? Cache Discard] The Consumer MUST 
always propagate an interaction to the portlet. If there is a 
perUser-scoped cache for this end-user, as a result of a prior interaction 
with this portlet, the Consumer MUST NOT rely on the contents of this 
cache, even if its expiration time indicates it is still valid. The reason 
for this is the interaction will very likely change the portlet's state, 
and therefore must not be diverted by the Consumer in favor of hitting its 
cache. The Consumer COULD send the validation token from the prior 
interaction's CacheControl in the interaction request, and in the event 
the portlet determines that the state change does not invalidate the 
cached content, will indicate that the Consumer may use the cached 
content, using the response mechanism described in the section on Caching. 
 

Reasoning: Make conformance statement wrt caching and interactions.  I 
believe this aligns us with JSR requirement that actions always propagate 
to the portlet.

[RT] While this is close to what we have discussed (& rejected) about 
interactions invalidating the cache, I think there is value to explicitly 
having the spec say something in this area. 

Alternate suggestion: [new section: 6.3.4 User Interactions and Caching] 
The Consumer MUST always propagate End-User interactions to the Producer. 
If available, the Consumer SHOULD send the validateTag corresponding to 
the MarkupParms supplied to the interaction invocation. If the Portlet 
determines that the interaction does not invalidate the cached content, 
will indicate that the Consumer can use the cached content via the 
useCachedMarkup flag of a returned MarkupContext structure. 

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>