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.
