Re: [wsrp] shared resource caching property

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

How about the following:

11.3 wsrp-extra:sharedResource

This extension describes an extended portlet url parameter with a name of "wsrp-sharedResource" where the value for this parameter carries a unique identifier for the resource, preferably in the form of a QName. The purpose of this extension is to allow broader caching of resources which are shared across many Portlets (e.g. script libraries such as v0.9 of dojo.js can be more broadly shared/cached when referred to as "{http://dojotoolkit.org/v0.9}dojo.js"). The Consumer may serve such a resource from any location and therefore Portlets referencing a shared resource MUST NOT depend on being called to serve the resource. Regardless of the setting of the wsrp-resourceCachability portlet url parameter, Consumers supporting this extension MUST treat resource URIs specifying the wsrp-sharedResource portlet url parameter as if the setting was "full". Portlets specifying the wsrp-sharedResource portlet url parameter SHOULD also set the wsrp-resourceCacheability portlet url parameter to a value of "full" so that Consumers not supporting this extension will still provide the maximum supported cacheability support.

Rich

Stefan Hepper <sthepper@hursley.ibm.com>

08/17/2007 07:14 AM

To	WSRP TC <wsrp@lists.oasis-open.org>
cc
Subject	[wsrp] shared resource caching property

Here what we currently have in the JSR 286 spec under the FULL caching
level:

"In order to enable sharing of the resource between different portlet
applications the portlet can set a unique ID, preferable a QName in the
QName.toString format, via the property key ResourceURL.SHARED on the
resource URL. This unique ID is intended to allow the portal application
identifying resource links that identify the same resource (e.g. in case
of a JavaScript library it could include the namespace + name of the
library + version). All downstream URLs will be assumed to have the same
sharing ID if no other unique ID is specified. For resource URLs that
have set the ResourceURL.SHARED property the portlet may not get called
for serving the resource as it may already be cached on the portlet
application when serving the same resource for a different portlet."


Stefan