[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
Eilon, I understand the clustering issues, and an implementation may try to invalidate whatever to let users expect a reasonable behavior. > We may want to provide a partial resolution along the lines of the previous > correspondence by suggesting that the Consumer would use the returned markup > from performInteraction rather than any cached version, but the challenge is > phrasing the suggestion in a way that does not imply fully-blown cache > invalidation. I see your point. Subbu > > Eilon > > -----Original Message----- > From: Subbu Allamaraju [mailto:subbu@bea.com] > Sent: Friday, February 28, 2003 17:10 > To: wsrp-wsia@lists.oasis-open.org > Subject: Re: [wsrp-wsia] [change request #187] Cacheability and perform*In > teraction > > > Michael Freedman wrote: > >>But, Alan, an action isn't cacheable. Why is there any ambiguity >>about >>whether actions propogate to the portlet? Are you concerned that >>readers will get confused now that we have added the capability for an >>action to be optimized by returning markup? I would be surprised by >>this, but if enough folks think action semantics are unclear a few words >>stating that "actions aren't cacheable and hence portlets will always >>receive them" should be sufficient. > > > This is not obvious from the spec. We need to say explicitly that > portlets always recived actions regardless of any cached markup. > > But the spec would be incomplete if it does not guarantee that the end > user gets to see updated markup after an action. If not by Alan's > proposal, how else do you propose to ensure this? > > Subbu > > >>As for clarifying how the Consumer manages the cache -- I personally >>think its clear enough however if folks think some clarifying words >>should be added then fine as long as the clarifying words define the >>semantics that have already been agreed on. I.e. we currently define no >>semantics for how an action impacts how a Consumer manages the cache. >>I.e. the impacts of actions on how the consumer manages the cache is >>exactly what we voted to defer to after 1.0. >> -Mike- >> >>Kropp, Alan wrote: >> >> >>>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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC