[Fwd: Re: [wsrp] Enable caching of resource content on the client]

[Michael Freedman <michael.freedman@oracle.com>]

Oops .. orginal only sent to Stefan ...

--- Begin Message ---

• From: Michael Freedman <michael.freedman@oracle.com>
• To: Stefan Hepper <sthepper@hursley.ibm.com>
• Date: Thu, 15 Feb 2007 10:08:31 -0800

Am I right that this is no more or less cacheable then regular render 
URLs?  If so it seems the primary issue is this (potentially) impacts 
all in-protocol URLs vs only those that need to use PortletURLs.  For 
wsrp 2.0 I would add information into the primer suggesting that 
cacheable resources be accessed via the http proxy mechanism.  I would 
then try and improve in-protocol getResource caching via future 
extensions/release.
    -Mike-

Stefan Hepper wrote:

> As mentioned in one of the WSRP calls currently caching of content 
> served through resource URLs on the client is basically not possible 
> for resource that are served through gR.
> Reason for this is that the resource URL that the consumer produces 
> needs to contain all nav state of all portlets on the page in order to 
> allow the gR call triggered with the URL to produce markup that 
> contains WSRP URLs again. This means that the URL will likely change 
> for each request and there will always be a cache miss on the client.
> So basically there are two different use cases:
> 1. render a resource that contains no or only resource WSRP tokens
> 2. render a resource that may contain any WSRP URL token
>
> Solutions I see:
> 1. say that the requiresRewrite is used to distinguish between these 
> two different use cases
> drawbacks: excludes use cases that only use namespacing or resouce 
> URLs and would normally be cachable
>
> 2. introduce a new attribute wsrp-markupContainsPortletURLs to 
> distinguish between these two use cases
> drawback: needs a spec change
>
>
> If we decide to open the spec for fixing gR I would opt for 2. if not 
> stick with a clarification to allow 1.
>
> Comments?
>
> Stefan
>

--- End Message ---