OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[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


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>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC