wsrp-interfaces message

Subject: RE: [wsrp-interfaces] Groups - Interfaces concall added

From: Rich Thompson <richt2@us.ibm.com>
To: wsrp-interfaces@lists.oasis-open.org
Date: Thu, 11 Oct 2007 10:40:52 -0400

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" <nlipke@bea.com>

10/10/2007 05:18 PM

To	"Michael Freedman" <michael.freedman@oracle.com>, <wsrp-interfaces@lists.oasis-open.org>
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:michael.freedman@oracle.com]
Sent: Tuesday, October 09, 2007 4:39 PM
To: wsrp-interfaces@lists.oasis-open.org
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: Michael.Freedman@oracle.com [mailto:Michael.Freedman@oracle.com]
        Sent: Thursday, October 04, 2007 11:31 AM
        To: wsrp-interfaces@lists.oasis-open.org
        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

References:
- RE: [wsrp-interfaces] Groups - Interfaces concall added
  - From: "Nathan Lipke" <nlipke@bea.com>