I would suggest being careful about
mixing cacheability concepts in with whether or not a particular resource
can be shared by two distinct components in the client environment.
Rich
From:
Michael Freedman <>
To:
Date:
11/08/2007 11:23 AM
Subject:
Re: [wsrp-interfaces] Multi-section
rendering (Renamed)
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 ():
1. 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.
2. 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.
3. 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.
4. 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.
5. 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
From:
"Nathan Lipke" <>
To:
"Michael Freedman" <>,
<>
Date:
11/07/2007 09:44 PM
Subject:
RE: [wsrp-interfaces] Multi-section
rendering (Renamed)
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:]
Sent: Wednesday, October 24, 2007 4:32 PM
To:
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
From:
"Nathan Lipke" <>
To:
"Nathan Lipke" <>,
"Michael Freedman" <>,
<>
Date:
10/16/2007 07:15 PM
Subject:
RE: [wsrp-interfaces] Groups - Interfaces
concall added
I added in cacheability based on wsrp-resourceCacheability.
Thanks,
Nate
From: Nathan Lipke [mailto:]
Sent: Wednesday, October 10, 2007 3:18 PM
To: Michael Freedman;
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:]
Sent: Tuesday, October 09, 2007 4:39 PM
To:
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 producerWhy
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 timesThis
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:
[mailto:]
Sent: Thursday, October 04, 2007 11:31 AM
To:
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.
---------------------------------------------------------------------
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
