[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [change request #187] Cacheability and perform*Interaction
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC