Subject: [Fwd: Re: [wsrp] Enable caching of resource content on the client]
Oops .. orginal only sent to Stefan ...
--- Begin Message ---
- From: Michael Freedman <email@example.com>
- To: Stefan Hepper <firstname.lastname@example.org>
- Date: Thu, 15 Feb 2007 10:08:31 -0800Am 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 ---