Re: [wsrp] [CR306] - Add default cacheControl

[Richard Jacob <richard.jacob@de.ibm.com>]

In general I agree, mapping the JSR168 expiration cache setting makes
sense.
However, what would the userScope be in that case.
JSR168 doesn't define a scope for it's cache.
Would it be "wsrp:all" as the default? And then could the portlet reset it
to another scope when delivering the markup?

Another question is whether the Consumer would really need to know whether
the markup is cacheable or not a priori?
Subbu, could you point out some use cases?

And what would it mean if the Consumer would know it a priori?
The cachability of the markup might change (depending on the navState of a
portlet for example), so what would the Consumer win if it knew this
default expiry setting?

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Standardization Technical Lead
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com


                                                                           
             Rich Thompson                                                 
             <richt2@us.ibm.co                                             
             m>                                                         To 
                                       wsrp@lists.oasis-open.org           
             10/19/2004 02:59                                           cc 
             PM                                                            
                                                                   Subject 
                                       [wsrp] [CR306] - Add default        
                                       cacheControl                        
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Document: Spec
Section: 5.1.11
Requested by: Subbu Allamaraju

Old Text:
New Text:   [O] CacheControl    cacheControl

Reasoning: We currently allow Producers to return cacheControl along with
markup so that the Consumer can try to cache the markup. However, the
Consumer will not know a priori whether a portlet's markup can be cached or
not. Some portlet programming models such as JSR168 allow portlet
developers to specify a default cache interval with the portlet's metadata.
In the current protocol, there is no means for exposing this metadata to
Consumers at discovery time in an interoperable manner.

By adding this field to the PortletDescription we can align WSRP with
JSR168 more tightly.

Errata? no