Re: [wsrp-interfaces] Re: [wsrp] Enable caching of resource contenton the client

[Michael Freedman <michael.freedman@oracle.com>]

I am opposed to dropping support for using portletURLs in a resource 
response as I expect our XPR/full-protocol Ajax support to be too 
cumbersome for many Ajax use cases.  I.e. most portlet use cases solved 
with WSRP 1.0.
     -Mike-

Richard Jacob wrote:

>I think option 1 excludes the most common use case where e.g. JS libs, CSS
>classes, etc. are loaded. We should still be optimized for a caching
>infrastructure and offload a) the producer and b) the consumer itself.
>I dont see why we should weaken that and provide a solution that from a
>plain infrastructure and performance viewpoint is worse than 1.0.
>I think the caching use cases are important enough to cleanly support them.
>
>Alternative 2 sounds feasible, in that case we would need to modify the
>EBNF of the resource URL.
>
>Another third solution I see is to drop the support for having portlet URLs
>in resources' markups.
>We talked today about the symmetrical behavior of gR and HTTP resource
>serving via the Consumer and the importance of having the same
>functionality for both.
>So enabling them in the one case while dissallowing them in the other seems
>inconsistent to me.
>
>What was the ability added for again? Afaik we tried to solve some Ajax use
>cases with it, right?
>On the other and we seem to say that a solution for Ajax won't be part of
>the 2.0 spec and we need to understand it more.
>So here again it would seem consistent to me that we dropped that
>capability and continue the Ajax discussion and add the necessary items
>post-2.0.
>
>Mit freundlichen Gruessen / best regards,
>
>        Richard Jacob
>______________________________________________________
>IBM Lab Boeblingen, Germany
>Dept. 2289, WebSphere Portal Server Development 1
>WSRP Team Lead
>WSRP Architecture & Standardization
>Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
>Email: mailto:richard.jacob@de.ibm.com
>
>
>                                                                           
>             Stefan Hepper                                                 
>             <sthepper@hursley                                             
>             .ibm.com>                                                  To 
>                                       WSRP TC <wsrp@lists.oasis-open.org> 
>             02/15/07 04:30 PM                                          cc 
>                                                                           
>                                                                   Subject 
>                                       [wsrp] Enable caching of resource   
>                                       content on the client               
>                                                                           
>                                                                           
>                                                                           
>                                                                           
>                                                                           
>                                                                           
>
>
>
>
>As mentioned in one of the WSRP calls currently caching of content
>served through resource URLs on the client is basically not possible for
>resource that are served through gR.
>Reason for this is that the resource URL that the consumer produces
>needs to contain all nav state of all portlets on the page in order to
>allow the gR call triggered with the URL to produce markup that contains
>WSRP URLs again. This means that the URL will likely change for each
>request and there will always be a cache miss on the client.
>So basically there are two different use cases:
>1. render a resource that contains no or only resource WSRP tokens
>2. render a resource that may contain any WSRP URL token
>
>Solutions I see:
>1. say that the requiresRewrite is used to distinguish between these two
>different use cases
>drawbacks: excludes use cases that only use namespacing or resouce URLs
>and would normally be cachable
>
>2. introduce a new attribute wsrp-markupContainsPortletURLs to
>distinguish between these two use cases
>drawback: needs a spec change
>
>
>If we decide to open the spec for fixing gR I would opt for 2. if not
>stick with a clarification to allow 1.
>
>Comments?
>
>Stefan
>
>
>
>  
>