Re: [wsrp] Caching and doing POST on resource URLs

[Rich Thompson <richt2@us.ibm.com>]

When considering the same issues relative
to pbia, we ended up walking a fine line of noting to the Consumer that
cache invalidation might be appropriate while not requiring it. The expectation
was that we eventually would want to provide means for the Portlet to be
explicit about how broad an invalidation was needed, but that effort hasn't
really moved forward yet. 

Relative to the current thread, I'm
not seeing compelling reasons to change this decision or the wording reflecting
it in the spec. The problem I see with extending the list of operations
is that "getResource" isn't named to suggest post characteristics
and therefore would be confusing in the list. Another possibility would
be describing the times when the Consumer developer should consider this
issue, but ensuring clarity in such a statement isn't trivial.

Rich

From:	Nathan E Lipke <nlipke@bea.com>
To:	Michael Freedman <michael.freedman@oracle.com>
Cc:	WSRP TC <wsrp@lists.oasis-open.org>
Date:	12/14/2007 01:41 PM
Subject:	Re: [wsrp] Caching and doing POST on resource URLs

---

If the resource response returns a portlet context with
new values for the portlet handle or state, I assume the cache should be
invalidated. 

However, there are cases where the portlet's handle does not change:

• state change is read-write
• the resource makes other changes to the portlet's markup through a non-spec mechanism (e.g. producer session)

In
these cases we do not currently have a mechanism to invalidate the cache.
This is regardless of the usage of the resource (verb and placement).

Some possible solutions:
1.        Do
nothing, force the portlet developer to turn off caching when doing such
operations
2.        Make
a note, stating that caching may cause unexpected results
3.        Add
a clearPortletCache attribute to ResourceContext
4.        Use
the portletContext as semaphore to clear the cache, Add a statement like:

• If the portlet context is returned the consumer SHOULD clear the portlet's cache, regardless of whether the handle and state values have changed.

Nate

Michael Freedman wrote: 
I would not make this editorial change as I think it makes
things more confusing not less -- as I suspect most portlets that use getResource
to further serve parts of their (inline) content will likely not rely on
consumer caching. 
    -Mike- 

Stefan Hepper wrote: 
Since we are in the progress of making some editorial
changes :-) here something we just noted: 
5.2.1.2 states: 
"Consumers should be aware that invoking performBlockingInteraction
and/or handleEvents may cause cached markup to become invalid." 

I think this should be extended to also include getResource triggered via
HTTP method POST, PUT, DELETE as in that case the portlet will likely make
state changes that render the previously cached markup invalid. 

Stefan 


--------------------------------------------------------------------- 
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  You may a link to this group and all your TCs
in OASIS 
at: 
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


--------------------------------------------------------------------- 
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  You may a link to this group and all your TCs
in OASIS 
at: 
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated entities,
that may be confidential, proprietary, copyrighted and/or legally privileged,
and is intended solely for the use of the individual or entity named in
this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then
delete it.