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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

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

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

Oops .. orginal only sent to Stefan ...
--- Begin Message ---
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 

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

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