This was the point of the "shared" resource cacheability level + URL
extension I talked about in my e-mail on 7/3 and copied below. Some of
this has already been added to JSR286
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
20 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.
25 URLs of the type FULL have the highest cacheability in the browser
as they do
not depend on any state of the portlet or page.
From e-mail sent on 7/3:
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-
Rich Thompson wrote:
One might think that the Consumer
could
simply filter the list of resources such that each is included only
once
per page, but such an approach is problematic. Most resources are not
"shareable";
that is, they are not fully instance based such that two uses do not
end
up stepping on each other. Unless a resource is known to be shareable,
the only safe thing for the Consumer to do on an html page is to wrap
portlets
with a second reference to a resource in an IFrame such that the
browser
provides the isolation that is potentially required. The item this
point
out to me is that we do not include a means to indicate a resource is
shareable
today (note this is not equivalent to being broadly cacheable) ...
perhaps
that needs to be added.
Rich
Some of my team members
came
up with an interesting use case related to this and I wanted to get
some
feedback:
Several portlets may
share
a common scripts or styles (e.g. Dojo). Some thoughts:
1. Is
there anyway to tell the consumer it does not need to call getMarkup()
for each portlet.
a. Possibly
a grouping mechanism
i.
Can/should
this be related to cookie groups
2. Can
the consumer merge head tags (link and script) that refer to the
document?
a. What
about tags with bodies?
Not solving this could
cause
large amounts of network traffic and worse multiple running of scripts
not intended to do so.
Any thoughts, thanks,
Nate
From: Michael Freedman [mailto:michael.freedman@oracle.com]
Sent: Wednesday, October 24, 2007 4:32 PM
To: wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces] Multi-section rendering (Renamed)
Additional questions:
1) What does it mean to have differing markupsections return non-null
clientAttributes?
2) Would it be better if the cacheability level is carried as an
extension
in CacheControl vs where you have it?
-Mike-
Rich Thompson wrote:
My comments in prep for tomorrow's call (in document order):
1. Is
there a proposed QName for this extension? We have normally put this in
the top-level header, but it certainly can be added late as that allows
the settled semantics to be better represented.
2. For
completeness the second paragraph should also indicate how the Consumer
indicates support for the extension.
3. This
may just be phrasing, but is the conformance statement in the second
paragraph
suggesting getMarkup invocations for each portlet-specified section or
just that each specified section should be requested? I ask because one
can debate whether SHOULD is too strong of conformance language given
the
ability to make valid arguments favoring differing implementation
styles
(in particular, one call per section vs one call for all sections). We
will also need to think carefully through cases where the portlet
specifies
a section which the Consumer has no idea how to handle (e.g. TabHeader).
4. It
wasn't obvious to me how different caching for each section was
included
until I dug into the schema. I suggest the descriptive text be more
explicit
about how the distinct information is returned. Once I had dug into
this,
the question arose as to whether MarkupContext was the right base for
MarkupSections
to extend. I suspect additional sections have more in common with
resources
than with the portlet's main markup and therefore MimeResponse would be
a more appropriate base.
5. In
11.3.3, I would recommend rewording the duplicate conformance statement
to eliminate the duplication. This both stops it from looking like an
additional
requirement and reduces likelihood of a later mismatch between the
statements.
6. 11.3.3
should require that all specified section names match the
Portlet-specified
ones.
7. I
would drop the complexity regarding choosing the main section. If
wsrp-extra:body
is requested, it appears in the main section. All other requested
sections
appear in extension fields.
8. Why
would the default cacheability be "full" for sections when it
is "page" for the main markup? Do we have good reasons for thinking
most sections will be reusable across all users, navStates, modes and
windowStates
or is this just an internal inconsistency developers will struggle with?
Rich
I added in cacheability based on wsrp-resourceCacheability.
Thanks,
Nate
From: Nathan Lipke [mailto:nlipke@bea.com]
Sent: Wednesday, October 10, 2007 3:18 PM
To: Michael Freedman; wsrp-interfaces@lists.oasis-open.org
Subject: RE: [wsrp-interfaces] Groups - Interfaces concall added
Thanks for the feedback,
Attached is a second draft which allows for multiple sections to be
sent
and received in a single request. It still allows for individual
sections
to be cached with their own unique validate tag.
--
Nate
From: Michael Freedman [mailto:michael.freedman@oracle.com]
Sent: Tuesday, October 09, 2007 4:39 PM
To: wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces] Groups - Interfaces concall added
Again inline:
Nathan E Lipke wrote:
I'll work on rewriting this tomorrow. See comments inline.
Michael Freedman wrote:
See inline:
Nathan E Lipke wrote:
If you think a more generic solution is needed with regards to
sections,
how does the following sound?
- Change the
MultiPhaseRender from
boolean to a list of Strings
- The consumer MUST call
getMarkup()
for each phase as enumerated
- Unless the consumer
has this phase
validly cached
- The consumer SHOULD
call the phases
in order (but cannot be guaranteed)
- The portlet MAY
decide each phases'
cacheability
- The response MUST
contain the phase
(sent in MarkupParams) as an extension to MarkupContext, to ensure the
extension was understood by the producer
Why
can't this other markup be returned with the body (request) in a
separate
extension that holds the markup for each of the indicated sections? Is
there a reason we need the extra getMarkup calls except when client
meta
data needs to be written?
Its expensive for the consumer to have to cache markup it cannot yet
output.
Also this would make it harder to cache individual phases.
I think this is only true for certain implementations -- others I can
imagine
can deal with this reasonably and could/would prefer fewer network
hops.
Maybe this complicates being able to add as a standard extension
in the specification itself as this may need more discussion/time to
work
through.
-
- The spec should
define well known
strings for wsrp-extra:head and wsrp-extra:body
We have found the HEAD section is often more cacheable than the portlet
content.
Our most common use case is as follows:
- The portlet relies on
a common
set of static (rewriting possible) styles and/or scripts in the
<head>
tag
- These are cached
initially (thus
getMarkup("head") is only called once per session)
- The portlet then
uses the scripts/styles
on many pages (states)
- getMarkup("body")
may
be called many times
This
limits the amount of traffic (and processing) to a minimum.
However, the producer is free not follow this by setting the "head"
to be non-cacheable.
That is was I suspected/expected -- you write-up however doesn't
describe
how this achieved -- the way things are worded now I would expect the
head
request to be cached using the same cache key as the body -- are you
going
to need extra "hints" like we have for resource requests that
allows the consumer to send less information and hence get greater
cacheability?
-Mike-
There are potentially two pieces to cache for the head section:
- The head
contents (e.g. the <script>
or <link> tag)
- May be
static, if the URLs are
constant
- Likely to
be long lived
- What the
tags refer to
- Probably
resource URLs
- Maybe
dynamic even if the URLs
are static
- Caching
is independent of the head
section
--
Nate
Michael Freedman wrote:
My preference is to separate the issue of rendering client response
meta
data (headers) from outputing markup in the client response that is
distinct
from the location of the portlets markup in that response. And while
I think that the header solution requires/will rely on this two phase
rendering
I don't think the rendering of other markup must/should. And finally
on the rendering of markup for other sections I would prefer a more
generic
solution that accounts for writing into another other well known or
nameable
section -- i.e. though head is the common/likely example why limit
ourselves
to this vs. providing a more generic solution?
As for caching, have you found in practice that the content for the
head
section truly is tied to the current state of the portlet and hence
should
be cached at the same level as the portlet markup? Or is this just
a convenience for the implementation?
-Mike-
Nathan Lipke wrote:
Attached please find a draft of our proposal to add support Head
section
(and headers) markup.
Our goals included:
Compatibility with JSR 286
Independent caching of the head and body sections
Support for most (all) markup languages
Reuse of existing WSRP types and methods
Thanks,
Nate
-----Original Message-----
From: Michael.Freedman@oracle.com
[mailto:Michael.Freedman@oracle.com]
Sent: Thursday, October 04, 2007 11:31 AM
To: wsrp-interfaces@lists.oasis-open.org
Subject: [wsrp-interfaces] Groups - Interfaces concall added
Interfaces concall has been added by Mr Michael Freedman
Date: Thursday, 11 October 2007
Time: 08:00am - 09:00am PT
Event Description:
1-888-967-2253 or +44 118 924 9000 (Europe)
meeting ID: 345337
passcode: 060606
Agenda:
Discuss extension proposal for carrying portlet markup in a
getmarkupresponse
that is intended for other locations in the consumers markup response.
I.e. return markup for the Head section.
Minutes:
View event details:
http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/event.php?event_id=16808
PLEASE NOTE: If the above link does not work for you, your email
application may be breaking the link into two pieces. You may be
able to
copy and paste the entire link address into the address field of your
web
browser.
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities,
that may be confidential, proprietary, copyrighted and/or legally
privileged,
and is intended solely for the use of the individual or entity named in
this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then
delete it.
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities,
that may be confidential, proprietary, copyrighted and/or legally
privileged,
and is intended solely for the use of the individual or entity named in
this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then
delete it.
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities,
that may be confidential, proprietary, copyrighted and/or legally
privileged,
and is intended solely for the use of the individual or entity named in
this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then
delete it.
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities,
that may be confidential, proprietary, copyrighted and/or legally
privileged,
and is intended solely for the use of the individual or entity named in
this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then
delete it.
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities,
that may be confidential, proprietary, copyrighted and/or legally
privileged,
and is intended solely for the use of the individual or entity named in
this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then
delete it.[attachment "multiSectionRendering-singleRequest.doc"
deleted by Rich Thompson/Watson/IBM]
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates
this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities,
that may be confidential, proprietary, copyrighted and/or legally
privileged,
and is intended solely for the use of the individual or entity named in
this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then
delete it.
|