I see some pros and cons in this proposal:
Positives:
- Metadata is extensible as additional
sections get defined
- Consumer has flexibility of
doing one invocation for all sections or multiple invocations for one section
at a time
Negatives:
- What is where depends on how
the Consumer decides to call the Portlet and How the Portlet wants to package
the response. I would suggest defining an extended type for carrying any
additional section. Whenever an additional section is returned (i.e. not
body & even if the body is not returned on this response), it is always
carried in an extension field of this defined type with an element name
which matches the section name.
- There seems to be minimal guidance
on when a new version of any additional section will be required while
the driving use case has the <head> section being invariant for most
types of state that are currently in the cache key for the main portlet
markup. If we really want to leverage separate caching, some means of reducing
the cache key needs to be communicated to the Consumer.
Rich
"Nathan Lipke"
<>
10/10/2007 05:18 PM
To
"Michael Freedman" <>,
<>
cc
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.
multiSectionRendering-singleRequest.doc
