Re: [wsrp] Caching of resources

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

The comment about templates is just
to point out that portlets can't expect the Consumer to work any magic
to make resources more cacheable when using templates. Now for those Consumers
whose templates merely cause Consumer URL rewriting to occur, they can
do something, but the portlet developer shouldn't expect that assistance
(though presumably one could tell by whether or not this portlet url parameter
is in the template ...).

I did not include some of the finer
nuances that a Consumer could rewrite as it starts to get complex very
quickly. For example, resource URLs could be rewritten as long as they
also specify "wsrp-cacheableResource=true", but not if the secondary
resource needs portletURLs rewritten (or access to portlet navState, etc).
Since the target is improving cacheability without sacrificing correctness,
I think leaving that complexity off the table is the right trade-off. 

A use case, which is becoming more common,
which this would affect is a script resource which dynamically loads other
script resources (i.e. the secondary resources are all cacheableResources
as well, for example the dojo script library can cause this). Do people
want to insert a sentence requiring Consumers to also rewrite resource
URLs as long as the secondary resources all specify "wsrp-cacheableResource=true"?

Rich

Michael Freedman <michael.freedman@oracle.com>

02/22/2007 06:19 PM

To	wsrp@lists.oasis-open.org
cc
Subject	Re: [wsrp] Caching of resources

Good start.  Can you explain the comment:
Note that this portlet url parameter only impacts Consumer
URL rewriting as the templates related to resource URIs have to allow for
resources to access the excluded state/functionality.

Also a suggested fixes:
The line : If both the wsrp-cacheableResource and wsrp-requiresRewrite
portlet URL parameters are set to true, the Consumer MUST parse the resource
for the purpose of rewriting namespace prefixing as per [Section
10.3].

should be changed to cover namespace prefixing AND resourceURL rewriting.
 A note would have to be included that either the cacheableResource
token is ignored in these subsequent resourceURLs or something else in
formal recognization of this error condition.
-Mike-