[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]