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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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

Subject: Re: [wsrp] Caching of resources

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


Michael Freedman <michael.freedman@oracle.com>

02/22/2007 06:19 PM

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.


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