wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Caching of resources
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Thu, 1 Mar 2007 09:37:33 -0500
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
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]