Since we said we should roll this comment into the Interfaces
subcommittee -- For discussion during Thursday's Interfaces concall:
I propose we expand section 10.2.1.1.3 to include 2 new
resourcecacheability levels (and rename some of the existing ones):
10.2.1.1.3.6 wsrp-resourceCacheability
Since resources can contain URIs
which the Consumer is required to rewrite, including those with a wsrp-urlType of render
or blockingAction, the Consumer will
typically place the state information needed to do such rewriting on
the resource URI. This decreases the likelihood of the resulting URI
being fetched from a browser or web cache simply due to a small change
in some portion of this state. This portlet url parameter provides an
indication to the Consumer that it can limit the amount of state it
places on the URI for the resource such that the likelihood of a
subsequent browser access being served from a browser/web cache is
increased. This parameter has five defined values ():
- shared: Resource URLs specifying a value of "shared"
are telling the Consumer that it doesn't need to place any reference to
the portlet or the producer managing this portlet on the URI and that
the resource URL itself is encoded in a means to ensure it represents a
unique resource across a shared (multiple producer) environment. For
out-of-band resource references this generally takes the form of using
a guid in the target name of the wsrp-url. For in-band resource this
typically relies on an URL extension that allows the Consumer to map
this resource reference to a previously defined resource guid. As a
result the resource generation SHOULD NOT depend on a non-null
PortletContext or RegistrationContext or any related portlet state such
as the NavigationalContext, mode or windowState.
In addition it MUST NOT use the wsrp-namespace token or include
URIs with a wsrp-urlType of render or blockingAction.
While the Consumer is required by the protocol to supply
values relative to mode and windowState, those supplied values are not
required to be respective to current values for any Portlet. The
resource can still require Consumer rewriting, but the Consumer will
only be able to do resource URI rewriting. These restrictions apply not
only to the resource directly referenced, but also to any secondary
resources the resource references, either directly or indirectly.
- producer: Resource URLs specifying a value of
"producer" are telling the Consumer that it does not need to place any
reference to the portlet on the URI. As a result the resource
generation SHOULD NOT depend on a non-null PortletContext or any
related portlet state such as the NavigationalContext,
mode or windowState.
In addition it MUST NOT use the wsrp-namespace token or include
URIs with a wsrp-urlType of render or blockingAction.
While the Consumer is required by the protocol to supply
values relative to mode and windowState, those supplied values are not
required to be respective to current values for any Portlet. The
resource can still require Consumer rewriting, but the Consumer will
only be able to do resource URI rewriting. These restrictions apply not
only to the resource directly referenced, but also to any secondary
resources the resource references, either directly or indirectly.
- portlet (renamed from full): Resource
URIs specifying a value of "portlet" are
telling the Consumer that it does not need to place any portlet state
on the URI. As a result, the resource generation SHOULD NOT depend on
the NavigationalContext, mode or windowState
and the generated resource MUST NOT include URIs with a wsrp-urlType of render
or blockingAction. While the Consumer is
required by the protocol to supply values relative to mode and windowState,
those supplied values are not required to be the respective current
values for the Portlet. However, if the Consumer's implementation style
permits it to supply the current value for any of the excluded items,
it is encouraged to supply those current values. The resource can still
require Consumer rewriting, but the Consumer will only be able to do
namespace rewriting and resource URI rewriting. These restrictions
apply not only to the resource directly referenced, but also to any
secondary resources the resource references, either directly or
indirectly.
- portletState: Resource
URIs specifying a value of "portletState"
are telling the Consumer that the resource needs access to the portlet
state (e.g. NavigationalContext), but
will not require Consumer processing which needs the state of any other
portlet. This restriction increases the cacheability of the resource
over specifying a value of "page" (e.g.
for the duration of a user interacting with some other portlet), but
the generated resource MUST NOT include URIs with a wsrp-urlType of render
or blockingAction. The resource can
still require Consumer rewriting, but the Consumer will only be able to
do namespace rewriting and resource URI rewriting. These restrictions
apply not only to the resource directly referenced, but also to any
secondary resources the resource references, either directly or
indirectly, unless such a secondary resource sets a value of "full" for the wsrp-resourceCacheability
portlet url parameter, at which point the tighter restrictions
associated with "full" will apply to that
resource and any others it references.
- page: Resource URIs
specifying a value of "page" are telling
the Consumer that this resource is no more cacheable than the
Consumer's page. Normally this occurs if either the referenced resource
or a secondary resource which this resource MAY contain URIs with a wsrp-urlType of render
or blockingAction. This value for the wsrp-resourceCacheability portlet url
parameter informs the Consumer that it will need the state required to
provide proper rewriting of such URIs when the user agent requests the
resource which the URI references. This is the default value for all
resource URIs which do not specify this portlet url parameter.
Note that this portlet url
parameter only impacts Consumer URL rewriting as the templates related
to resource URIs provide other means to achieve the equivalent
functionality (see [Section 6.1.3] and [Section
10.2.2.9]).
In addition we obviously need to define the details of what the in-band
getResource receives for the two new cache levels (well just producer
actually -- as in-band sharing relies on an undefined (future
extension). For the "producer" case I suggest we allow PortletContext
to be nil. Furthermore we would have to specify that the values of
RuntimeContext.namespacePrefix and RuntimeContext.portletInstanceKey
are undefined and can't be relied on.
-Mike-
Michael Freedman wrote:
I want to
discuss whether we have enough resource cacheability levels and if so
whether the full level is sufficiently defined. I am interested in the
use cases where one wants resource caching in the browser on either a
per producer level and/or shared across multiple producers (potentially
on different servers).
Per producer use case: A JSR portlet application exposes a single wsrp
producer. Its quite common for portlets in this application to share
resources. How do our resource cacheability levels allow this to be
expressed for in-band and out-of-band resources?
Multiple producer use case: More and more portlet environments are
relying on sophisticated MVC systems to develop/run/support their
portlets. These MVC systems often depend on a slew of javascript and
even UI based resources. As these exist at a "platform" level vs.
application level its common for distinct producers to rely on the same
underlying platform. Because the volume of such resources can be large
its important to share (the browser caching) of these resources as much
as possible. How does our resource cacheability levels allow this to
be expressed for in-band and out-of-band resources?
The concern I have is that our definition of the "full" level only
talks about omitting portlet state. For the out-of-protocol case one
still seems to need to encode the portletid (or the actual namespaceid)
because "full" still requires the consumer to be able to support the
namespace tag. For the in-procotol case we haven't defined a meaning
for dispatching a getResource to an empty/null PortletContext.
Thoughts?
-Mike-
|