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:

 
Is
     there anyway to tell the consumer it does not need to call getMarkup() for
     each portlet.

 
  
Possibly
      a grouping mechanism

 

                                                              
i.     
Can/should
this be related to cookie groups

 
Can
     the consumer merge head tags (link and script) that refer to the document?

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

Sent: Wednesday, October 24, 2007
4:32 PM

To:


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): 

 
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 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.[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.