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



I think we are saying the same thing, but I think it is important to make a stronger statement than any supplied value is ignored. The key is that the cacheable parameter's value inherits to all secondary resources.

Rich



Michael Freedman <michael.freedman@oracle.com>

02/27/2007 12:53 PM

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





By particular comment was based on you specifically calling out the need to parse for namespace tokens.  I wanted to be sure we were clear that its both namespace tokens and resourceURLs that are rewritten in this scenario.   On your question:
"
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"?"

I prefer we spoecify that when a parent resource sets wsrp-cacheableResource=true then this value is ignored for all children resources and their descenedents.  
   -Mike-


Rich Thompson wrote:


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-



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