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):
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.
For completeness the
second
paragraph should also indicate how the Consumer indicates support for
the
extension.
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).
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.
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.
11.3.3 should
require that all
specified section names match the Portlet-specified ones.
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.
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 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:
[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]
