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

[Rich Thompson <richt2@us.ibm.com>]

I would suggest being careful about
mixing cacheability concepts in with whether or not a particular resource
can be shared by two distinct components in the client environment.

Rich

From:	Michael Freedman <michael.freedman@oracle.com>
To:	wsrp-interfaces@lists.oasis-open.org
Date:	11/08/2007 11:23 AM
Subject:	Re: [wsrp-interfaces] Multi-section rendering (Renamed)

---

This was the point of the "shared" resource
cacheability level + URL extension I talked about in my e-mail on 7/3 and
copied below.  Some of this has already been added to JSR286 

In order to enable sharing of the resource between different portlet applications
the portlet can set a unique ID, preferable a QName in the QName.toString
format, via the property key ResourceURL.SHARED on the resource URL. This
unique ID is intended to allow the portal application identifying resource
links
that identify the same resource (e.g. in case of a JavaScript library it
could
20 include the namespace + name of the library + version). All downstream
URLs
will be assumed to have the same sharing ID if no other unique ID is specified.
For resource URLs that have set the ResourceURL.SHARED property the portlet
may not get called for serving the resource as it may already be cached
on the
portlet application when serving the same resource for a different portlet.
25 URLs of the type FULL have the highest cacheability in the browser as
they do
not depend on any state of the portlet or page.

From e-mail sent on 7/3:
Since we said we should roll this comment into the Interfaces subcommittee
-- For discussion during Thursday's Interfaces concall:

I propose we expand section 10.2.1.1.3 to include 2 new resourcecacheability
levels (and rename some of the existing ones):

10.2.1.1.3.6 wsrp-resourceCacheability

Since resources can contain URIs which the Consumer is required to rewrite, including those with a wsrp-urlType of render or blockingAction, the Consumer will typically place the state information needed to do such rewriting on the resource URI. This decreases the likelihood of the resulting URI being fetched from a browser or web cache simply due to a small change in some portion of this state. This portlet url parameter provides an indication to the Consumer that it can limit the amount of state it places on the URI for the resource such that the likelihood of a subsequent browser access being served from a browser/web cache is increased. This parameter has five defined values ():
1.        shared: Resource URLs specifying a value of "shared" are telling the Consumer that it doesn't need to place any reference to the portlet or the producer managing this portlet on the URI and that the resource URL itself is encoded in a means to ensure it represents a unique resource across a shared (multiple producer) environment.  For out-of-band resource references this generally takes the form of using a guid in the target name of the wsrp-url.  For in-band resource this typically relies on an URL extension that allows the Consumer to map this resource reference to a previously defined resource guid.  As a result the resource generation SHOULD NOT depend on a non-null PortletContext or RegistrationContext or any related portlet state such as the NavigationalContext, mode or windowState.  In addition it MUST NOT use the wsrp-namespace token or include URIs with a wsrp-urlType of render or blockingAction. While the Consumer is required by the protocol to supply values relative to mode and windowState, those supplied values are not required to be respective to current values for any Portlet.  The resource can still require Consumer rewriting, but the Consumer will only be able to do resource URI rewriting. These restrictions apply not only to the resource directly referenced, but also to any secondary resources the resource references, either directly or indirectly.

2.        producer:  Resource URLs specifying a value of "producer" are telling the Consumer that it does not need to place any reference to the portlet on the URI.  As a result the resource generation SHOULD NOT depend on a non-null PortletContext or any related portlet state such as the NavigationalContext, mode or windowState.  In addition it MUST NOT use the wsrp-namespace token or include URIs with a wsrp-urlType of render or blockingAction. While the Consumer is required by the protocol to supply values relative to mode and windowState, those supplied values are not required to be respective to current values for any Portlet.  The resource can still require Consumer rewriting, but the Consumer will only be able to do resource URI rewriting. These restrictions apply not only to the resource directly referenced, but also to any secondary resources the resource references, either directly or indirectly.

3.        portlet (renamed from full): Resource URIs specifying a value of "portlet" are telling the Consumer that it does not need to place any portlet state on the URI. As a result, the resource generation SHOULD NOT depend on the NavigationalContext, mode or windowState and the generated resource MUST NOT include URIs with a wsrp-urlType of render or blockingAction. While the Consumer is required by the protocol to supply values relative to mode and windowState, those supplied values are not required to be the respective current values for the Portlet. However, if the Consumer's implementation style permits it to supply the current value for any of the excluded items, it is encouraged to supply those current values. The resource can still require Consumer rewriting, but the Consumer will only be able to do namespace rewriting and resource URI rewriting. These restrictions apply not only to the resource directly referenced, but also to any secondary resources the resource references, either directly or indirectly.

4.        portletState: Resource URIs specifying a value of "portletState" are telling the Consumer that the resource needs access to the portlet state (e.g. NavigationalContext), but will not require Consumer processing which needs the state of any other portlet. This restriction increases the cacheability of the resource over specifying a value of "page" (e.g. for the duration of a user interacting with some other portlet), but the generated resource MUST NOT include URIs with a wsrp-urlType of render or blockingAction. The resource can still require Consumer rewriting, but the Consumer will only be able to do namespace rewriting and resource URI rewriting. These restrictions apply not only to the resource directly referenced, but also to any secondary resources the resource references, either directly or indirectly, unless such a secondary resource sets a value of "full" for the wsrp-resourceCacheability portlet url parameter, at which point the tighter restrictions associated with "full" will apply to that resource and any others it references.

5.        page: Resource URIs specifying a value of "page" are telling the Consumer that this resource is no more cacheable than the Consumer's page. Normally this occurs if either the referenced resource or a secondary resource which this resource MAY contain URIs with a wsrp-urlType of render or blockingAction. This value for the wsrp-resourceCacheability portlet url parameter informs the Consumer that it will need the state required to provide proper rewriting of such URIs when the user agent requests the resource which the URI references. This is the default value for all resource URIs which do not specify this portlet url parameter.

Note that this portlet url parameter only impacts Consumer URL rewriting as the templates related to resource URIs provide other means to achieve the equivalent functionality (see [Section 6.1.3] and [Section 10.2.2.9]).

In addition we obviously need to define the details of what the in-band getResource receives for the two new cache levels (well just producer actually -- as in-band sharing relies on an undefined (future extension).  For the "producer" case I suggest we allow PortletContext to be nil.  Furthermore we would have to specify that the values of RuntimeContext.namespacePrefix and RuntimeContext.portletInstanceKey are undefined and can't be relied on.
    -Mike-

Michael Freedman wrote: I want to discuss whether we have enough resource cacheability levels and if so whether the full level is sufficiently defined.  I am interested in the use cases where one wants resource caching in the browser on either a per producer level and/or shared across multiple producers (potentially on different servers).

Per producer use case:  A JSR portlet application exposes a single wsrp producer.  Its quite common for portlets in this application to share resources.  How do our resource cacheability levels allow this to be expressed for in-band and out-of-band resources?

Multiple producer use case:  More and more portlet environments are relying on sophisticated MVC systems to develop/run/support their portlets.  These MVC systems often depend on a slew of javascript and even UI based resources.  As these exist at a "platform" level vs. application level its common for distinct producers to rely on the same underlying platform.  Because the volume of such resources can be large its important to share (the browser caching) of these resources as much as possible.  How does our resource cacheability levels allow this to be expressed for in-band and out-of-band resources?

The concern I have is that our definition of the "full" level only talks about omitting portlet state.  For the out-of-protocol case one still seems to need to encode the portletid (or the actual namespaceid) because "full" still requires the consumer to be able to support the namespace tag.  For the in-procotol case we haven't defined a meaning for dispatching a getResource to an empty/null PortletContext.   Thoughts?
  -Mike-

Rich Thompson wrote:

One might think that the Consumer could simply filter the list of resources such that each is included only once per page, but such an approach is problematic. Most resources are not "shareable"; that is, they are not fully instance based such that two uses do not end up stepping on each other. Unless a resource is known to be shareable, the only safe thing for the Consumer to do on an html page is to wrap portlets with a second reference to a resource in an IFrame such that the browser provides the isolation that is potentially required. The item this point out to me is that we do not include a means to indicate a resource is shareable today (note this is not equivalent to being broadly cacheable) ... perhaps that needs to be added.

Rich

From:	"Nathan Lipke" <nlipke@bea.com>
To:	"Michael Freedman" <michael.freedman@oracle.com>, <wsrp-interfaces@lists.oasis-open.org>
Date:	11/07/2007 09:44 PM
Subject:	RE: [wsrp-interfaces] Multi-section rendering (Renamed)

---

Some of my team members came up with an interesting use case related to
this and I wanted to get some feedback: 
  
Several portlets may share a common scripts or styles (e.g. Dojo). Some
thoughts: 
1.        Is
there anyway to tell the consumer it does not need to call getMarkup()
for each portlet. 
a.        Possibly
a grouping mechanism 
                    
                     
                    i.
     Can/should
this be related to cookie groups 
2.        Can
the consumer merge head tags (link and script) that refer to the document?
a.        What
about tags with bodies? 
  
Not solving this could cause large amounts of network traffic and worse
multiple running of scripts not intended to do so.
  
Any thoughts, thanks, 
  
Nate

---

From: Michael Freedman [mailto:michael.freedman@oracle.com]
Sent: Wednesday, October 24, 2007 4:32 PM
To: wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces] Multi-section rendering (Renamed)
  
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):
1.        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.
2.        For completeness the second paragraph should
also indicate how the Consumer indicates support for the extension.
3.        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).
4.        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.
5.        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.
6.        11.3.3 should require that all specified
section names match the Portlet-specified ones.
7.        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.
8.        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" <nlipke@bea.com>
To:	"Nathan Lipke" <nlipke@bea.com>, "Michael Freedman" <michael.freedman@oracle.com>, <wsrp-interfaces@lists.oasis-open.org>
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:nlipke@bea.com]
Sent: Wednesday, October 10, 2007 3:18 PM
To: Michael Freedman; wsrp-interfaces@lists.oasis-open.org
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.
          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]

          --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
          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.

          --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php