RE:[wsrp-interfaces] Groups - Invalidation Caching Proposal.html uploa ded

Title: RE:[wsrp-interfaces] Groups - Invalidation Caching Proposal.html uploa ded

Is the following use case covered under "Action changes may affect more then one rendition"? 

A portal shows a list of purchase orders and the purchasing manager (user) modifies the item count in one of her open orders. Redisplaying all orders is expensive (database lookup to get current status) so the portlet developer would like a simple way to "invalidate" only one of the orders currently displayed.

Do we need to re-visit how portlet instances (consumer side renditions) are identified for both caching and eventing (identifying the source of an event seems a related issue)? e.g If  events or complex caching is supported then consumer-side portlet renditions MUST have a unique identification?

regards,

Andre

-----Original Message-----

From:  [mailto:]

Sent: 04 February 2004 00:23

To: 

Subject: [wsrp-interfaces] Groups - Invalidation Caching Proposal.html

uploa ded

The document Invalidation Caching Proposal.html has been submitted by Michael Freedman () to the WSRP Interfaces SC document repository.

Document Description:

WSRP 2.0 Proposal for supporting invalidation-based caching.

Download Document:  

http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/5285/Invalidation%20Caching%20Proposal.html

View Document Details:

http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/document.php?document_id=5285

PLEASE NOTE:  If the above links do not work for you, your email application

may be breaking the link into two pieces.  You may be able to copy and paste

the entire link address into the address field of your web browser.