RE: [wsrp-interfaces] Multi-section rendering (Renamed)

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 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]