[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-wsia] [change request #187] Cacheability and perform*Interaction
I recall that we agreed (2 times) not to add invalidation caching semantics. Andre, Mike: could you please bring us up-to-date concerning the JSR168 topic. Following this discussion I would say that we shouldn't now add invalidaton caching semantics and second Mike. However I like Andre's statement about the markup returned in performXInteraction. We added the ability to return markup for optimization. And indeed it should be handled like a performXInteraction call followed by a getMarkup call - same semantics here. We can add the first sentence for clarification, but shouldn't that then be a conformance statement, i.e. MUST? Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com |---------+----------------------------> | | Andre Kramer | | | <andre.kramer@eu.| | | citrix.com> | | | | | | 02/28/2003 10:51 | | | AM | |---------+----------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: wsrp-wsia@lists.oasis-open.org | | cc: | | Subject: RE: [wsrp-wsia] [change request #187] Cacheability and perform*In teraction | >--------------------------------------------------------------------------------------------------------------------------------------------------| Mike, Do you agree that JSR 168 caching and the perUser UserScope have incompatible semantics? If that is the case, then I don't recall a formal vote when this was brought to the TC's attention, only an agreement not to add cache invalidation to 1.0. But I may be in error on both of the above. While I believe both Alan and Rich's text would help improve the spec, fundamentally, I don't like the SHOULDs and incomplete semantics we are now discussing. How about just stating: "Action, blockingAction and render URL activations must be propagated to the producer." "Any mark-up returned by performXInteraction must either be ignored or treated as if it was returned by getMarkup() with equivalent mark-up related parameters." "UserScopes perUser and forAll do not define how a consumer cache is to be updated after a performXInteraction() on a portlet." With yesterday's change request resolution to make UserScope open-ended, I can more easily define a "perApplicationUser" that adds: "Any content cached under the perApplicationUser scope for a portlet must be considered expired after a performXInteraction() on the portlet". Then it will be safe to implement perUser and perApplicationUser in the same way at a consumer, but a producer will not be able to rely on it. Still, it would really help if we could declare caching scopes names (and authentication method names) as we can add registration property names via Appendix B.1. regards, Andre -----Original Message----- From: Michael Freedman [mailto:Michael.Freedman@oracle.com] Sent: 27 February 2003 20:51 To: wsrp-wsia@lists.oasis-open.org Subject: Re: [wsrp-wsia] [change request #187] Cacheability and perform*In teraction That being said, then I think the clarification we would need is to explain how a Consumer handles the optimized case when Markup is returned from an Action. Wouldn't this be more straightforward/clearer? I suggest: "If an action returns markup that corresponds to an entry in the Consumer cache, the Consumer SHOULD discard its cache entry and use the returned markup. Likewise, if an action returns a CacheControl structure without markup that corresponds to an entry in the Consumer cache, the Consumer SHOULD update its cache entry with the corresponding information in the structure" I make this a SHOULD rather then a MUST because returning markup from an action is an optimization. The Consumer isn't currently required to recognize/use this optimized markup in the first place -- i.e. it could choose to call render and presumably receive the same results. This capability though unlikely is important to the issue above. I.e. a Consumer is just as free to ignore optimized markup that impacts its caches. As a side note, the wording you suggested related to validateTag is misleading. The cache key/content returned by the action need not [and often isn't] related to the validateTag passed in. Typically, the action itself identifies the paritcular piece of content [onwe has navigated to]. -Mike- Rich Thompson wrote: The reason I proposed the alternate text was that I thought it was easy to read Alan's text in the manner Mike did. The proposed alternate does capture Alan's key point that Interactions always propagate to the Producer (assumed currently) and proposes how a Consumer can find out whether some cached markup can be used at the end of invoking perform*Interaction (a performance enhancement). Rich Thompson "Kropp, Alan" <Alan.Kropp@vignette.com> 02/27/2003 02:21 PM To: "'Michael Freedman'" <Michael.Freedman@oracle.com>, wsrp-wsia@lists.oasis-open.org cc: Subject: RE: [wsrp-wsia] [change request #187] Cacheability and perform*In teraction An important objective of this change request is the point that actions must propagate to the portlet, regardless of the existence of unexpired cached content. Is that not a requirement of the JSR? Would not its absence from WSRP be a serious problem for WSRP-JSR synchronization on interaction processing? I fail to see how this somehow resurrects the invalidation question, but I'd gladly revisit the wording if folks think this is the implication. It is definitely not my intent. Read carefully, either my or Rich's text says absolutely nothing about the Producer telling the Consumer to invalidate its cache. The text is entirely focused on directing how the Consumer manages the cache when processing an action. I do not agree that the spec already gives clarity on this point, and feel its explicit mention, in the section on action processing, lends the clarity I feel is missing. Alan -----Original Message----- From: Michael Freedman [mailto:Michael.Freedman@oracle.com] Sent: Thursday, February 27, 2003 11:01 AM To: wsrp-wsia@lists.oasis-open.org Subject: Re: [wsrp-wsia] [change request #187] Cacheability and perform*Interaction I strongly object to this change request and ask that it be withdrawn. We have already discussed and rejected twice now adding invalidation semantics in 1.0. This change request introduces no new technical issue to challenge the prior discussions and therefore should not be considered. We should stand by the rules we have established. To head off arguments that it introduces something new ... the change request asks for two things: first to clarify whether actions are cacheable, and second how an action affects the cache for subsequent getMarkups. Is there really any confusion concerning whether actions are cacheable? The specification defines no provisions for such behavior, only markup. Why do we need to clarify something that is clearly not supported by the protocol? As for how actions affect the cache -- this is precisely the discussion we have had twice prior to this change request -- and have twice prior voted to not define invalidation caching in 1.0. -Mike- Rich Thompson wrote: 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> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- 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] | [List Home]