Re: [wsrp] shared resource caching property

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

08/17/2007 07:14 AM

To

WSRP TC <>

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