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.
multiSectionRendering-singleRequest.doc
